Rate limiting is one of the best topics to learn for a system design interview. It's small. You can understand it in an afternoon. And when it comes up, most candidates wave at it and move on, so saying something specific stands out.
I want to give you enough to sound like you've actually built one.
What rate limiting is for
A rate limiter caps how many requests a client can make in a window of time. 100 requests per minute, 5 logins per hour, that kind of thing.
People assume it's just about stopping abuse. It is partly that. But the bigger reason is protecting yourself from your own success. A traffic spike, a buggy client retrying in a tight loop, or one heavy user can knock over a service that's fine 99% of the time. Rate limiting is how you stay up when something upstream goes wrong.
So the one-liner I'd give in an interview: rate limiting protects a service from being overwhelmed, whether the cause is malicious, accidental, or just popular.
The algorithms, ranked by how often they come up
There are four worth knowing. You don't need to implement them on a whiteboard. You need to know the tradeoffs.
Fixed window. Count requests per clock-aligned window, like per calendar minute. Reset the count when the minute rolls over. Dead simple. The flaw: a client can send a burst at 11:00:59 and another at 11:01:00 and double their allowance across the boundary. Fine for rough limits, bad when the limit really matters.
Sliding window. Smooths out the boundary problem by weighting the previous window. Slightly more state, much fairer. This is what I'd reach for as a sane default.
Token bucket. A bucket fills with tokens at a steady rate up to a cap. Each request spends a token. Empty bucket means rejected or queued. The nice property is it allows short bursts (you spend saved-up tokens) while holding a steady average. This is the one to mention if the interviewer cares about bursty traffic, like an API that's quiet then busy.
Leaky bucket. Requests queue and drain at a fixed rate. Smooths output completely, but adds latency and can drop requests when the queue fills. Good when you're protecting something downstream that needs an even flow.
If you only remember two, remember token bucket and sliding window. Those cover most real answers.
Where it lives, and why that's the hard part
Picking an algorithm is the easy half. The part that impresses is knowing where the limiter runs and how it stays consistent.
In a single server, you keep counts in memory and you're done. Nobody runs a single server.
Once you have many servers behind a load balancer, each one only sees a slice of the traffic. If each keeps its own count, a client allowed 100 requests can actually get 100 times the number of servers. So you need shared state.
The common answer is a central store like Redis. Every server reads and writes the counter there. Redis is fast and has atomic operations, so you can increment and check a limit without a race. Mention that you'd use an atomic operation or a small Lua script so the read-and-check happens as one step, not two. That detail signals you've thought about concurrency.
The tradeoff: now every request makes a network call to Redis, and Redis becomes a thing that can fail. So you talk about what happens when it's down. Do you fail open (allow everything, protect availability) or fail closed (reject everything, protect the backend)? There's no universal right answer, and saying that, then picking one for the situation, is exactly what a good interviewer wants.
What to actually say in the room
Here's a tight script when rate limiting comes up:
- Name why you're adding it. Protecting the backend, not just blocking abuse.
- Pick token bucket or sliding window and say why for this traffic.
- Note that limits are per-key, and the key matters. Per user, per IP, per API token. Per-IP punishes people behind shared networks, so prefer an account key when you have one.
- Move the state to Redis for the multi-server case, with an atomic increment.
- Mention failure mode (open vs closed) and the response you return: a 429 status with a
Retry-After header so clients know when to come back.
That's maybe ninety seconds of talking and it covers the algorithm, the distributed problem, the key design, and the failure handling. Most candidates cover one of those four.
How to get this to stick
Read about it once, then explain it out loud as if to an interviewer. The gap between recognizing token bucket and being able to describe it cold is where people lose points. Practicing the script above in a mock interview is worth more than reading another article, including this one.
It's a small topic. That's the point. The return on learning it well is high.