Lesson 4.2 · 20 min
Rate limiter
Token bucket, sliding windows, the window-edge attack, and the Redis race that lets a 6th request through.
The idea in plain words
A rate limiter is a bouncer that lets each person in only so many times a minute. It stops one client (or attacker) from overwhelming a service that everyone shares.
The problem it solves
A shared service can be swamped by one client: a bug in a loop, a scraper, or someone guessing passwords. Without limits, everyone else suffers.
How it works
- Decide who to count (a user, an API key or an IP address) and the limit (say 100 per minute).
- For each request, look up that client’s count for the current window.
- Under the limit: allow it and add one. Over: reject it with 429 and say when to retry.
- Different algorithms count differently: fixed windows, sliding windows, or a bucket of tokens that refills over time.
- With many servers, keep the counts in one shared store and update them atomically.
Example
A login endpoint allows 5 attempts per minute per account. An attacker trying 1,000 passwords gets 5 tries a minute instead of 1,000, turning seconds of work into days.
Key terms
- Rate limit
- The maximum number of requests a client may send in a time window, such as 100 per minute.
- 429 Too Many Requests
- The HTTP status sent back when a client is over its limit.
- Token bucket
- Each client has a bucket that refills at a steady rate; each request spends a token.
- Fixed vs sliding window
- Counting per clock minute versus over the last 60 seconds at any moment.
- Burst
- Many requests in a short moment, which some algorithms allow and others don’t.
In this lesson you'll learn
- The 5 rate-limiting algorithms, and when each one fits.
- How to run one limiter across many servers without race conditions.
- How to answer a rate-limiter design question from start to finish.
Sections
- Theory: why and where
- Theory: 5 algorithms
- Theory: edge attack
- Design: requirements
- Design: many servers
- Design review
Cheat sheet
| Reject with | 429 + Retry-After |
|---|---|
| Fixed window edge | up to 2× the limit |
| Token bucket | capacity = burst, refill = rate |
| Many servers | atomic INCR / Lua in Redis |
| Store down? | security → fail closed |
The interactive simulations and the scored design review load with JavaScript.