25. Rate Limiting
1
The picture to keep in your head2
25.1 Why limit?3
25.2 What are the algorithms?4
25.3 How do the algorithms compare?5
25.4 How does distributed rate limiting with Redis work?6
25.5 Where should the limiter go?7
25.6 What do 429 and rate-limit headers look like?8
25.7 How do you handle bots and abuse?9
Memory card and where the analogy breaks10
Practice: five levels11
Interview questions12
Solutions13
Sources14
Code lab25. Rate Limiting
25.3 How do the algorithms compare?
3 min read+10 XP
At the club: The bowl of passes is friendly to groups. The steady queue is kind to the bar staff. The hourly clicker is easy but gameable at midnight. The guest book is perfect but needs a thick book. Two clickers are the practical middle.
In the system:
| Algorithm | Bursts | Accuracy | Memory per client | Best for |
|---|---|---|---|---|
| Token bucket | Allowed, up to capacity | Good | 2 numbers | Most APIs; per-user and per-key limits |
| Leaky bucket | Smoothed into a steady stream (adds delay) | Good | Queue or 2 numbers | Protecting a fragile downstream; traffic shaping |
| Fixed window | Up to 2× at boundaries | Weak at edges | 1 counter | Simple quotas (per day), low stakes |
| Sliding log | None beyond the limit | Exact | One entry per request | Low limits where exactness matters (5 logins per 15 min) |
| Sliding window counter | Small error | Very close | 2 counters | High-volume APIs needing accuracy cheaply |
How to choose in an interview:
- Default to the token bucket: simple, burst-friendly, cheap, and easy to explain.
- Mention the fixed window's boundary problem and the sliding window counter as the fix if they ask about accuracy.
- Use a sliding log for small, security-critical limits (login attempts), where memory per key is tiny anyway.
- Use a leaky bucket when the point is to smooth traffic into something that can't take bursts.
Memory code: "Bucket by default, sliding for precision, leaky to protect the fragile."