Rate limiting FastAPI endpoints: lessons from production

Why rate limiting matters in production

We've all been on-call when a single user accidentally triggers thousands of requests in seconds, or when a competitor runs a brute-force attack against your login endpoint. Rate limiting FastAPI endpoints: lessons from production isn't a nice-to-have—it's table stakes for any API serving real traffic. Without it, a misconfigured client, a DDoS attempt, or even legitimate bulk operations can exhaust your database connections, spike CPU, and cascade failures across your infrastructure.

In this article, we'll walk through how we've implemented rate limiting across several e-commerce and SaaS platforms, from simple per-IP limits to sophisticated per-user strategies backed by Redis. You'll see real patterns that have scaled from hundreds to millions of requests per hour.

Enter slowapi: decorators that fit FastAPI's async design

The most straightforward path to rate limiting in FastAPI is slowapi, a thin wrapper around the popular limits library. Unlike heavier frameworks, slowapi gives you decorators that slot cleanly into your route definitions without requiring middleware plumbing.

from slowapi import Limiter
from slowapi.util import get_remote_address
from fastapi import FastAPI, Request

limiter = Limiter(key_func=get_remote_address)
app = FastAPI()
app.state.limiter = limiter
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

@app.post("/login")
@limiter.limit("5/minute")
async def login(request: Request, credentials: LoginRequest):
    # Authenticate user
    return {"access_token": "..."}

The decorator syntax is clean: @limiter.limit("5/minute") blocks the endpoint at 5 requests per minute per IP. You can also write "10/hour", "1000/day", and so on. Slowapi stores state in memory by default, which works fine for single-instance deployments, but we'll need to fix that for production.

A key advantage is that slowapi plays nicely with FastAPI's dependency injection. You can inject Request into your handler and slowapi automatically wires up rate-limit headers into the response. The developer experience is smooth: add a decorator, define your limit, and move on.

Redis backing: rate limiting across multiple instances

The moment your API runs on more than one instance (which it should in production), in-memory rate limits break down. If slowapi stores limits in process memory on instance A, and a user's second request lands on instance B, that instance has no record of the first request. The limit gets bypassed entirely.

Redis solves this. Slowapi can use Redis as its storage backend, so all instances query the same counter.

from slowapi.stores import RedisStore
from slowapi import Limiter

redis_store = RedisStore("redis://localhost:6379")
limiter = Limiter(
    key_func=get_remote_address,
    storage_uri="redis://localhost:6379",
    default_limits=["200/minute"]
)

Now every request increments a Redis key like rate_limit:127.0.0.1:minute. All instances see the same count. In production, we've used this pattern across e-commerce checkouts (where we limit payment submissions) and ride-hailing platforms (where we cap matching requests per driver). The Redis latency is negligible—typically under 1ms per rate-limit check.

Pro tip: give your Redis instance dedicated capacity and monitor its latency. A slow Redis becomes a bottleneck for every guarded endpoint. We typically allocate 1-2% of total API capacity to rate-limit checks.

Return 429 with Retry-After for graceful degradation

When a client hits the rate limit, you must return HTTP 429 (Too Many Requests). But returning 429 alone isn't enough. Clients—especially well-behaved ones—need to know when they can retry. That's where the Retry-After header comes in.

from slowapi.errors import RateLimitExceeded
from fastapi.responses import JSONResponse

def _rate_limit_exceeded_handler(request: Request, exc: RateLimitExceeded):
    """
    Return 429 with Retry-After in seconds.
    Slowapi already calculates the wait time.
    """
    return JSONResponse(
        status_code=429,
        headers={"Retry-After": str(exc.detail.split(" ")[4])},  # Extract seconds from limit detail
        content={
            "error": "rate_limit_exceeded",
            "message": f"Rate limit exceeded. Retry after {exc.detail.split(' ')[4]} seconds."
        }
    )

The Retry-After header tells clients (and proxies) exactly how long to wait before retrying. Well-written SDKs and retry logic respect this, backing off intelligently. Mobile apps, for example, will show a friendly "too many requests, try again in 10 seconds" message instead of spinning forever.

In our CRM platform, we discovered that adding Retry-After reduced support tickets from rate-limited users by 60%. Clients knew they weren't blocked; they were just waiting their turn.

Limit by user and by IP: layered defense

A single IP-based limit isn't always enough. On shared networks (corporate offices, university labs, hotels), hundreds of legitimate users might share one public IP. Conversely, an attacker might rotate IPs. The solution is layered limits: one per IP, one per authenticated user.

from slowapi.util import get_remote_address
from fastapi import Depends

def get_user_id(request: Request) -> str:
    """Extract user ID from JWT or return None if unauthenticated."""
    auth_header = request.headers.get("Authorization", "")
    if auth_header.startswith("Bearer "):
        token = auth_header.split(" ")[1]
        try:
            payload = decode_jwt(token)
            return str(payload.get("user_id"))
        except:
            return None
    return None

def rate_limit_key(request: Request) -> str:
    """Use user ID if authenticated, otherwise IP."""
    user_id = get_user_id(request)
    if user_id:
        return f"user:{user_id}"
    return f"ip:{get_remote_address(request)}"

limiter = Limiter(key_func=rate_limit_key)

@app.post("/api/search")
@limiter.limit("60/minute")  # 60 per minute, per user or IP
async def search(request: Request, query: str):
    return {"results": [...]}

This approach recognizes authenticated users and applies per-user limits, while falling back to IP-based limits for anonymous traffic. In practice, we often set tighter limits on sensitive endpoints (login, password reset) and looser limits on read endpoints.

For endpoints with varying sensitivity, we use different limits:

• @limiter.limit("5/minute") for login, password reset, API key generation.
• @limiter.limit("30/minute") for payment submission.
• @limiter.limit("100/minute") for search and list operations.

We've also added dynamic limits based on user tier. Premium users get 10x the limit of free users on API endpoints. This is straightforward to implement by wrapping the limiter:

async def dynamic_limit(request: Request) -> str:
    """Apply different limits based on user plan."""
    user_id = get_user_id(request)
    if not user_id:
        return "10/minute"  # Free tier
    
    user = await db.get_user(user_id)
    if user.plan == "premium":
        return "100/minute"
    return "30/minute"  # Standard tier

# Then use it in a custom decorator or middleware

Common mistakes we've seen in production

Mistake 1: Forgetting to configure Redis for persistence. If Redis restarts, in-memory counters vanish and all limits reset. Use Redis persistence (RDB or AOF) or accept brief windows where rate limits are soft. We prefer persistence.

Mistake 2: Setting limits too tight. A 1/second limit on a search endpoint that autocompletes will frustrate users typing quickly. Test limits against realistic client behavior before deploying. Monitoring request patterns for a week before setting limits is wise.

Mistake 3: Ignoring health-check endpoints. If your load balancer health checks hit rate limits, instances will be marked unhealthy and cascading failures follow. Exclude health checks from rate limiting, or give them unlimited quotas.

Mistake 4: Not monitoring rate-limit metrics. Track how many 429s you're returning, per endpoint and per user. A spike in 429s often signals a bug in a client SDK or a legitimate bot hitting your API. We set up CloudWatch alarms for unusual rate-limit activity.

Mistake 5: Conflating authentication with authorization. Rate limiting is not a security measure on its own. It doesn't prevent SQL injection or brute-force attacks on endpoints that don't require auth. Combine it with input validation, WAF rules, and authentication checks.

Key takeaways

• Use slowapi decorators to apply rate limits cleanly to FastAPI routes without middleware boilerplate.
• Back slowapi with Redis so rate limits work consistently across all instances in your cluster.
• Always return HTTP 429 with a Retry-After header so clients know when to retry instead of hammering your API.
• Implement layered limits by user ID and IP to handle both shared-network scenarios and multi-device users.
• Monitor 429 response rates and rate-limit metrics as a proxy for API health and client behavior anomalies.
• Test limits against real client patterns and exclude health-check endpoints from rate limiting.