New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
Nothing stops one client from hammering your busiest endpoint hundreds of times a second.
What you'll have at the end
A per-key sliding-window limiter live on one endpoint, rejecting calls past a configured ceiling with a 429 and a real Retry-After, verified with a burst script that shows the fixed-window boundary-doubling gone and the same ceiling holding across multiple worker processes sharing one Redis counter.
You need
A FastAPI endpoint already live and taking real traffic, where each request already carries a caller identity such as an API key, and a Redis instance the service can already reach.
Not covered
Rate limiting every route in the app, or building one shared limiter service other teams call into: this hardens the one endpoint taking the hit.
Leans on
Choose local caching or Redis
settles whether Redis is even the right shared store for this service before building a per-key counter on top of it.
Namespace your cache keys so two different lookups never collide
the same namespacing discipline the `rl:` prefix here follows, worth applying to every other key sharing the instance.
Checked 19 Aug 2026
Part of the Backend Caching cookbook