system-design pattern
Rate Limiter Design
Protect APIs from abuse with different rate limiting algorithms. Critical for system stability.
Time
O(1) per request check
Space
O(users × rules) for distributed
🧠Mental Model
“A nightclub bouncer with a clicker - only lets X people in per hour, tracks the count, resets the counter.”
Verbal cue: Count requests, compare to limit, allow or deny.
🎯Recognition Triggers
When you see these patterns in a problem, consider this approach:
rate limitthrottleAPI abuseDDoS protectionquota
💡Interview Tips
- 1Token bucket allows bursts, leaky bucket smooths traffic
- 2Always use Redis Lua scripts for atomic operations
- 3Discuss response headers: X-RateLimit-Remaining, Retry-After
⚠️Common Mistakes
- ✕Not handling distributed environments (multiple servers)
- ✕Forgetting about race conditions in counter updates
- ✕Not considering different limits per user tier