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
Memory card and where the analogy breaks
3 min read+10 XP
The memory card (tear this page out)
| # | Question | Memory code |
|---|---|---|
| 25.1 | Why limit? | Limit the few so the room works for everyone |
| 25.2 | Algorithms? | Passes refill, queues drip, clickers reset, logs remember, and two clickers estimate |
| 25.3 | Comparing them? | Bucket by default, sliding for precision, leaky to protect the fragile |
| 25.4 | Distributed with Redis? | One list for every door, updated in one move |
| 25.5 | Where to limit? | Gate for floods, door for tickets, bar for drinks |
| 25.6 | 429 and headers? | Say "too many", say how many are left, and say when to come back |
| 25.7 | Bots and abuse? | Limit what the attacker wants, not just who they claim to be |
The whole chapter in one line: Use a token bucket (or a sliding window counter) per client, keep the count in one atomic shared place, limit at the layer that understands the key, answer 429 with when to retry, and key abuse limits on the thing being attacked.
Where the analogy breaks
- A bouncer can see faces. An API sees only keys, tokens and IP addresses, and many users can share one IP while one attacker can use thousands.
- A club's passes are physical, and you can't take two at once. A shared counter isn't: without an atomic update, two servers can hand out the same last pass.
- A turned-away guest goes home. A rejected program retries immediately unless you tell it when to come back.
Quick check
Five questions on this chapter. Pick an answer, then check it.
quiz