Rate Limiter
VERY COMMONRate limiter is asked in nearly every system design interview at FAANG. It is how Cloudflare blocks 72 billion threats per day and how Stripe enforces API quotas across millions of merchants. You will compare four algorithms, design a distributed counter in Redis, and handle the fail-open vs fail-closed trade-off that trips up most candidates.
- Compare four rate limiting algorithms and pick the right one
- Design atomic check-and-increment with Redis Lua scripts
- Handle the fail-open vs fail-closed decision under pressure
Visual Solutions
Step-by-step animated walkthroughs with capacity estimation, API design, database schema, and failure modes built in.
Cheat Sheet
Key concepts, trade-offs, and quick-reference notes for Rate Limiter. Everything you need at a glance.
Anti-Patterns
Common design mistakes candidates make. Wrong approaches vs correct approaches for each trap.
Failure Modes
What breaks in production, how to detect it, and how to fix it. Detection metrics, mitigations, and severity ratings.
Start simple. Build to staff-level.
“I would design a rate limiter for 500M DAU using the sliding window counter algorithm in Redis. Each user record takes 400 bytes (60 sub-window counters at 6 bytes each), totaling 200 GB across a Redis cluster. Every request triggers a Lua script that atomically reads, checks, and increments in under 5ms. Rules live in MySQL, synced to local cache on each gateway. The limiter sits at the API gateway so rejected requests never reach app servers. For burst tolerance, token bucket runs as a secondary algorithm. On Redis failure, the system fails open with local in-memory fallback.”
Token Bucket Algorithm
EASYWe chose token bucket (not leaky bucket) because it allows controlled bursts up to tokens while maintaining an average rate of R tokens/sec. No tokens left? 429.
Core Feature DesignFixed Window Counter
EASYWe considered fixed window first because it costs only 20 bytes per key in Redis. We chose sliding window instead because at window boundaries, 2x the limit can pass.
Core Feature DesignSliding Window Counter
STANDARDWe chose sliding window counter (not sliding log) because it weights two adjacent fixed windows by overlap, giving 86% less memory while eliminating the boundary burst problem.
Core Feature DesignRedis Lua Scripting
STANDARDWe chose Lua scripts (not distributed locks, not MULTI/EXEC) because they read, check, increment, and set TTL in one atomic operation. No race window, 0.1ms execution time.
High Level DesignDistributed Rate Counting
STANDARDWe use a shared Redis counter (not per-server local memory) because with 10 servers and round-robin load balancing, local counters give the user 10x the allowed rate.
High Level DesignFail-Open vs Fail-Closed
STANDARDWe chose fail-open (not fail-closed) when Redis is down because availability beats perfect throttling. Fail-closed turns a cache blip into a full API outage.
Fault ToleranceRate Limit HTTP Headers
EASYWe include X-RateLimit-Remaining on all responses (not only 429) so clients self-throttle proactively. Retry-After on 429 prevents thundering herd.
System APIsHot Key Splitting
TRICKYWe split hot keys into 10 sub-keys (not one key per user+endpoint) because one enterprise key doing 50K RPS saturates a single Redis shard. Splitting drops shard CPU from 100% to 10%.
Fault Tolerance