Rate Limiting
Caps request rate per client/API key/IP to protect services, ensure fairness, and prevent abuse.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Rate Limiting is non-negotiable.
① What it is (30 seconds)
Caps request rate per client/API key/IP to protect services, ensure fairness, and prevent abuse.
② How it works in system design
Algorithms: token bucket (allows burst), leaky bucket (smooth), sliding window (accurate). Store counters in Redis with TTL. Return 429 + Retry-After header.
Typical placement
Client→Edge / Gateway→Rate→Services→Data stores
③ Concrete system design example
Scenario: Public API: 1000 req/min per API key. Redis INCR with sliding window per key. Gateway rejects before hitting expensive backend; monetize higher tiers.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Token bucket vs fixed window? | Fixed window has burst at window edges; sliding window or token bucket smoother. |
| Distributed rate limit? | Central Redis cluster or approximate per-node limits with sync — trade accuracy vs speed. |
| Rate limit vs throttle? | Limit rejects; throttle queues or delays excess requests. |
⑤ Seen in these system designs
- Rate Limiter — full design
- API Gateway — edge enforcement
- ChatGPT System — token quotas
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Algorithm named
- 429 response
- Redis counter pattern
- Burst handling
- Per-tenant fairness