Edge and reliability / Intermediate / 5 min
Rate limiting: who gets a 429
Token bucket, fixed window and sliding window under steady, bursty and window-edge traffic.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A rate limiter caps how many requests a client can make, answering 429 Too Many Requests above the limit.
- Why it matters
- It protects the service from abuse, bugs and one noisy client using up everyone’s capacity.
- The trade-off
- A fixed window lets double bursts through at the edges; a token bucket allows short bursts; a sliding window is fairer but costs more memory.
- Say it in an interview
- "A token bucket per user in Redis: a steady refill rate with a burst size, and 429 with Retry-After when empty."
Check yourself
Fixed window, limit 10/s. How many requests can get through in a short burst across a window boundary?
Answer: Up to 20. 10 at the end of one window plus 10 at the start of the next, all within a fraction of a second.
Which algorithm allows short bursts while keeping the long-run average at the limit?
Answer: Token bucket. Tokens accumulate up to the bucket size, so a burst can spend saved tokens; refill rate caps the average.
Which HTTP status code means "too many requests"?
Answer: 429. 429 Too Many Requests, often with a Retry-After header.