Lesson 27 / 32
Design a Rate Limiter
Design a distributed rate limiter with token buckets, Redis counters and helpful rate-limit response headers.
Token bucket
Each client has a bucket refilled at a fixed rate up to a cap. A request spends one token; if the bucket is empty, reject with 429. It allows short bursts.
Distributed state
With many API servers, counters must be shared. Keep them in Redis with atomic increments and per-key TTLs so any server enforces the same limit.
Tell the client
Return X-RateLimit-Remaining and Retry-After headers so well-behaved clients back off instead of hammering.
Quick check: Which algorithm naturally permits a short burst above the steady rate?
- Token bucket
- Fixed window counter
- Leaky bucket (as a queue)
- Sliding window log with no cap
Answer
Token bucket — Accumulated tokens let a client spend several at once, up to the bucket cap.