YOUR BRIEF
What to work through
Work through a rate limiter as a spoken system design interview. Start by clarifying the scope, sketch a working design and explain the trade-offs behind your choices.
- Identify clients by user id, IP address or API key
- Limit requests by configurable rules, such as 100 requests a minute per user
- Answer over-limit requests with 429 and headers for the limit, what remains and when it resets
- Change rules without a deploy
BEFORE YOU START
Constraints to discuss
- Under 10 ms added to each request
- 1 million requests a second across 100 million daily users
- Works across many servers; counts may be eventually consistent between nodes
- Keeps behaving safely when the counter store fails
- Low memory per client
Need a starting point?
Watch for these common gaps as you prepare:
- Limiting only in the client, where requests can be forged
- Counters in each server’s memory, so limits drift with the number of servers
- Read then write on the counter with no atomic step
- No answer for what happens when Redis is down
- Queueing rejected requests instead of failing fast
- IP limits set so low that users behind one NAT block each other
Why this question is in the collection
These sources connect the problem to company interview reports or preparation guides. They do not guarantee what a company will ask you.