Rate Limiting
Protect systems and ensure fairness under bursty traffic.
📌 Key IdeaRate limiting constrains request velocity per key (user/IP/API key). Common algorithms: token bucket, leaky bucket, fixed/sliding window.
Problem it solves
- Unbounded request traffic can overload APIs and downstream dependencies.
- Without limits, one noisy client can consume disproportionate capacity and hurt others.
Why It Matters
- Protects service reliability and latency during bursts and abuse scenarios.
- Ensures fair-share usage across users/tenants.
When to Use
- Public APIs and auth endpoints under abuse risk.
- Protecting expensive dependencies from traffic spikes.
- Fair-share limits across tenants.
When NOT to Use
- Global one-size limits without tenant context.
- Only edge limits when internal fanout can still overload downstreams.
Code Variations
Token bucket check (conceptual)java
if (bucket.tryConsume(1)) {
return handle(req);
}
return tooManyRequests();Implement with Redis/Lua for distributed correctness.
Algorithm trade-offs
| Aspect | Fixed window | Sliding window | Token bucket |
|---|---|---|---|
| Simplicity | ✅ easiest | ⚠ medium | ⚠ medium |
| Burst handling | ⚠ boundary burst | ✅ smoother | ✅ explicit burst budget |
| Typical use | basic per-minute limits | fair API gating | real-time APIs |
Interview Q&A
Quick Cheat Sheet
Status code429 Too Many Requests
Best defaultToken bucket for smooth burst control.
DistributedUse Redis atomic scripts/counters.