“Design a rate limiter” is one of the most common system design interview questions. It is small enough to finish in 45 minutes, but it touches algorithms, distributed state and latency trade-offs. This guide follows the order that works well in an interview, with links into two recorded SDE Skills sessions where the problem is worked live.
| Algorithm | How it works | Trade-off |
|---|---|---|
| Token bucket | A bucket with fixed capacity refills at a preset rate. Each request takes a token; an empty bucket rejects. | Allows short bursts up to the capacity. Simple and widely used. |
| Leaky bucket | Requests enter a queue that is drained at a fixed rate. | Smooth output rate, but a poor fit for synchronous accept/reject HTTP calls. |
| Fixed window counter | Count requests per clock window (for example per minute). | Easy to code, but up to 2x the limit can pass at a window boundary. |
| Sliding window log | Store a timestamp per request and count those inside the window. | Exact, but memory grows with traffic. |
| Sliding window counter | Weighted average of the previous and current window counts. | Close to exact with tiny memory. A strong default answer. |
Walkthroughs of token bucket (8:15), the leaky bucket trade-off (34:34) and the fixed window boundary problem (42:57) are in the session below.
With many API hosts, per-host counters drift apart and the real limit becomes “limit x number of hosts”. Common fixes:
Mention monitoring (how many requests are rejected, per rule), how rules are configured and reloaded without a deploy, and what happens if the limiter itself fails (fail open vs fail closed).
Rate limiter system design mock interview
Rate limiting algorithms session
SDE Skills is a volunteer-run 501(c)(3) nonprofit with free weekly system design sessions on Zoom. See the schedule, or read How to Prepare for a System Design Interview and Object-Oriented Design Interview Prep.