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.

Practice

1.

What is the main purpose of rate limiting in a FastAPI application?

easy

A. To speed up database queries

B. To control how often users can call API endpoints

C. To add more routes automatically

D. To change the API response format

Solution

1. Step 1: Understand rate limiting concept

   Rate limiting restricts the number of requests a user can make in a time period.

2. Step 2: Identify the purpose in FastAPI

   It protects the app from overload and abuse by controlling request frequency.

3. Final Answer:

   To control how often users can call API endpoints -> Option B

4. Quick Check:

   Rate limiting = Control request frequency [OK]

Hint: Rate limiting means controlling request frequency [OK]

Common Mistakes:

• Thinking it speeds up queries
• Confusing with routing features
• Assuming it changes response format

2.

Which of the following is the correct way to import a rate limiter middleware in FastAPI?

from fastapi import FastAPI
from _____ import RateLimiterMiddleware

app = FastAPI()
app.add_middleware(RateLimiterMiddleware, max_requests=5, window_seconds=60)

easy

A. fastapi_utils

B. fastapi.middleware

C. fastapi_rate_limit

D. fastapi_limiter

Solution

1. Step 1: Recall FastAPI rate limiting libraries

   FastAPI commonly uses the external package 'fastapi_limiter' for rate limiting middleware.

2. Step 2: Match import statement

   The correct import is from 'fastapi_limiter' to get RateLimiterMiddleware.

3. Final Answer:

   fastapi_limiter -> Option D

4. Quick Check:

   RateLimiterMiddleware import = fastapi_limiter [OK]

Hint: Rate limiter middleware comes from fastapi_limiter package [OK]

Common Mistakes:

• Using built-in fastapi.middleware (no rate limiter there)
• Confusing with unrelated packages
• Misspelling package names

3.

Given this FastAPI code snippet using fastapi_limiter:

from fastapi import FastAPI
from fastapi_limiter import FastAPILimiter
from fastapi_limiter.depends import RateLimiter
import aioredis

app = FastAPI()

@app.on_event("startup")
async def startup():
    redis = await aioredis.from_url("redis://localhost")
    await FastAPILimiter.init(redis)

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

What happens if a user calls /items 4 times within 10 seconds?

medium

A. The server crashes due to Redis error

B. All 4 requests succeed with message 'Success'

C. The 4th request is blocked with a 429 Too Many Requests error

D. The 4th request is delayed but eventually succeeds

Solution

1. Step 1: Understand RateLimiter parameters

   RateLimiter(times=3, seconds=10) allows 3 requests every 10 seconds per user.

2. Step 2: Analyze 4 requests in 10 seconds

   The 4th request exceeds the limit and triggers a 429 error response.

3. Final Answer:

   The 4th request is blocked with a 429 Too Many Requests error -> Option C

4. Quick Check:

   Requests > limit = 429 error [OK]

Hint: Requests over limit cause 429 error response [OK]

Common Mistakes:

• Assuming all requests succeed
• Thinking server crashes on limit
• Believing requests get delayed instead of blocked

4.

Identify the error in this FastAPI rate limiting setup:

from fastapi import FastAPI
from fastapi_limiter import FastAPILimiter
import aioredis

app = FastAPI()

@app.on_event("startup")
async def startup():
    redis = aioredis.from_url("redis://localhost")
    await FastAPILimiter.init(redis)

@app.get("/data", dependencies=[Depends(RateLimiter(times=2, seconds=5))])
async def get_data():
    return {"data": "info"}

medium

A. Missing await before aioredis.from_url call

B. RateLimiter times parameter must be 5 or more

C. FastAPILimiter.init should not be awaited

D. Redis URL must use http:// instead of redis://

Solution

1. Step 1: Check aioredis.from_url usage

   aioredis.from_url is an async function and must be awaited to get the Redis client.

2. Step 2: Identify missing await

   The code calls aioredis.from_url without await, causing a coroutine object instead of Redis client.

3. Final Answer:

   Missing await before aioredis.from_url call -> Option A

4. Quick Check:

   Async calls need await [OK]

Hint: Always await async Redis client creation [OK]

Common Mistakes:

• Forgetting await on async functions
• Misunderstanding RateLimiter parameters
• Using wrong Redis URL scheme

5.

You want to limit users to 10 requests per minute globally across multiple FastAPI instances behind a load balancer. Which setup is best?

1. Use in-memory counters in each instance
2. Use Redis with fastapi_limiter shared by all instances
3. Use local file storage for counts
4. Disable rate limiting

hard

A. Option 2: Use Redis with fastapi_limiter shared by all instances

B. Option 1: Use in-memory counters in each instance

C. Option 3: Use local file storage for counts

D. Option 4: Disable rate limiting

Solution

1. Step 1: Understand distributed rate limiting need

   Multiple FastAPI instances require a shared store to track request counts globally.

2. Step 2: Evaluate options

   In-memory counters are local to each instance, causing inconsistent limits. Local files are not suitable for concurrency. Disabling rate limiting removes protection.

3. Step 3: Choose Redis shared by all instances

   Redis is a fast, centralized store that all instances can use to enforce limits consistently.

4. Final Answer:

   Option 2: Use Redis with fastapi_limiter shared by all instances -> Option A

5. Quick Check:

   Distributed rate limiting needs shared Redis [OK]

Hint: Use shared Redis for consistent limits across instances [OK]

Common Mistakes:

• Using local memory causing inconsistent limits
• Using file storage which is slow and unsafe
• Disabling rate limiting ignoring abuse risks