Rate Limiter for a Public API
mediumOpen designVery commonly asked~45 minHLD roundBar raiserSDE-2 and upAmazonGoogleUberAtlassianFlipkartRazorpayRate LimitingCachingResilience
The question, as asked
“We expose a public API and some clients are hammering it. Design a rate limiter for us.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Limit per what? API key, user ID, IP, or endpoint — the answer changes the storage key and the cardinality you have to hold.
- What are the limits, and are they uniform? A flat 100 req/s is a different system from per-tier plans with burst allowances.
- How exact does it have to be? Ask outright whether a small overshoot during a race is acceptable — this single answer decides whether you need coordination.
- Where does it sit — at the gateway/edge, or inside each service? Edge protects everything behind it; in-process protects only itself.
- What happens on a breach: 429 with a Retry-After, queue the request, or silently degrade?
- What's the traffic scale, and how many distinct keys? 10k keys fits in memory; 100M does not.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.