EASYwalkthrough
Fixed Window Counter
The simplest rate limiting algorithm, and the one we reach for when implementation speed matters more than precision. We divide time into fixed windows (say 60-second intervals), maintain one counter per user per window, and reject requests once the counter exceeds the threshold.
That is the entire implementation. But this simplicity hides a critical flaw we must explain in any interview: the boundary burst problem.
“One Redis key, one INCR command, one TTL.”
Consider a limit of 100 requests per minute. A user sends 100 requests at second 59 of window 1, then 100 more at second 0 of window 2.
In a 2-second span straddling the boundary, 200 requests pass through, double the intended limit. Implication: downstream services expecting a steady 100 requests per minute receive 200 in a 2-second burst, which can overwhelm connection pools and trigger cascading timeouts.
We chose fixed window counter (not sliding window counter) only when we have a second defense layer underneath. AWS API Gateway uses fixed window counters for its default throttling precisely because it combines them with a token bucket layer that absorbs the boundary burst. Trade-off: we gave up boundary accuracy for memory per user and single-command latency.
What if the interviewer asks: 'How do we fix the boundary burst without changing algorithms?' We layer a token bucket on top: the fixed window enforces the per-minute cap while the token bucket smooths the per-second rate within the window.
Related concepts