Rate limiting in FastAPI - Step-by-Step Execution

Concept Flow - Rate limiting

Incoming Request

↓

Check Rate Limit

↓

Reject

↓

Send 429

When a request arrives, the system checks if the user has exceeded allowed requests. If yes, it rejects with an error; if no, it processes the request.

Execution Sample

FastAPI

from fastapi import FastAPI, Request, HTTPException, Depends
from fastapi_limiter import FastAPILimiter
from fastapi_limiter.depends import RateLimiter
from fastapi_limiter.aio.inmemory import InMemoryKeyStorage

app = FastAPI()

@app.on_event("startup")
async def startup():
    await FastAPILimiter.init(InMemoryKeyStorage())

@app.get("/items", dependencies=[Depends(RateLimiter(times=2, seconds=10))])
async def read_items():
    return {"message": "Success"}

This FastAPI code limits the /items endpoint to 2 requests every 10 seconds per user.

Execution Table

Step	Request Number	Time (s)	Rate Limit Check	Action	Response
1	1	0	Allowed (0 < 2)	Process Request	200 Success
2	2	5	Allowed (1 < 2)	Process Request	200 Success
3	3	8	Blocked (2 >= 2)	Reject Request	429 Too Many Requests
4	Wait	11	Reset Limit (time window passed)	Allow Next Requests	N/A
5	4	12	Allowed (0 < 2)	Process Request	200 Success

💡 Requests blocked after exceeding 2 requests within 10 seconds; limit resets after 10 seconds.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After Reset	After 4
request_count	0	1	2	2 (blocked)	0 (reset)	1
time_seconds	0	0	5	8	11	12

Key Moments - 2 Insights

Why is the third request blocked even though it happens before 10 seconds?

Because the rate limit allows only 2 requests in 10 seconds. The third request exceeds this limit as shown in execution_table row 3.

What happens after 10 seconds have passed since the first request?

The rate limit counter resets, allowing new requests as shown in execution_table row 4 and 5.

Visual Quiz - 3 Questions

Look at the execution table, what is the response for the second request?

A 200 Success

B 429 Too Many Requests

C 500 Server Error

D Request Timeout

💡 Hint

Check row 2 under the Response column in the execution_table.

At which step does the rate limit reset allowing new requests?

A Step 3

B Step 2

C Step 4

D Step 1

💡 Hint

Look at the execution_table row where the time reaches 11 seconds.

If the limit was changed to 3 requests per 10 seconds, what would happen at step 3?

A Request would be blocked

B Request would be allowed

C Request would timeout

D Request would cause server error

💡 Hint

Compare request_count and times allowed in execution_table row 3.

Concept Snapshot

Rate limiting controls how many requests a user can make in a time window.
In FastAPI, use dependencies with RateLimiter(times, seconds).
If requests exceed limit, server returns 429 error.
Limit resets after the time window passes.
This protects servers from overload and abuse.

Full Transcript

Rate limiting in FastAPI works by checking each incoming request against a set limit of allowed requests in a time frame. If the user has not exceeded the limit, the request is processed normally. If the limit is exceeded, the request is rejected with a 429 Too Many Requests error. The limit resets after the specified time window, allowing new requests. This example limits the /items endpoint to 2 requests every 10 seconds. The execution table shows the first two requests succeed, the third is blocked, and after 10 seconds the limit resets allowing requests again. Variables like request_count and time_seconds track the state of requests and timing. Understanding when requests are blocked or allowed helps prevent server overload and ensures fair use.