01
Prompt
Design a distributed rate limiter. Per-user, per-API, across 100 app servers. 100K QPS. Sliding-window (not fixed-window).
Time budget: 30 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.
Exercise · Infrastructure
Rate Limiter
Whiteboard exercise. Try the problem cold, then reveal the rubric to self-score.
02
Hints (progressive — click to reveal)
Hint 1
Fixed-window has boundary burst (2× at window edge). Sliding-window smooths this.
Hint 2
Centralized Redis with atomic INCR + TTL beats in-memory per-server counters.
Hint 3
Token bucket for request-rate; leaky bucket for outflow rate. Different properties.
03
Rubric — 10 points
- +2 Sliding-window (log or counter) not fixed-window — discusses boundary burst problem
- +2 Centralized Redis INCR per key (user+endpoint); atomic + TTL-based window
- +1 Token bucket for flexibility: sustained rate + burst allowance
- +1 Multi-tier: global → tenant → endpoint → user; deny if ANY exceeded
- +1 Fail-open on Redis outage (don't block all traffic) or circuit-breaker to local fallback
- +1 Returns 429 with Retry-After header + rate-limit metadata (X-RateLimit-Remaining)
- +1 Discusses cost: ~10 Redis calls/sec/user; plans for millions of active users
- +1 Per-user priorities: premium users higher limits; internal bots separate bucket
Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.
04
Red flags (things that tank the interview)
- Fixed-window counter (2x burst at boundary)
- Per-server in-memory counter (bypassed by rotating through servers)
- No fail-open on Redis down (entire service blocks)
- Synchronous slow Redis in request path (should be async-capable)
- Single global limiter with no tenant/user granularity