The Problem With Fixed Windows
Fixed window divides time into intervals, say, 1-minute blocks. You count requests per block and reject when the count exceeds the limit. Simple. But it has a flaw that will burn you in production.
Imagine a limit of 100 requests per minute. A client sends 90 requests at 10:00:58 (end of one window) and 90 more at 10:01:02 (start of the next). That is 180 requests in 4 seconds. 80% over the intended limit, but each individual window only shows 90. Both pass.
This is called the boundary burst problem. Cloudflare published an engineering blog post about it in 2017. They found that fixed windows allowed real attack traffic to slip through during window boundaries because attackers could time their bursts to straddle two windows. The fix was switching to sliding window counters across their entire edge network.
All three limiters are configured to allow ten requests a second. Each line is the number they actually admitted in the trailing second, which is the rate the service behind them feels.
The dashed line is the promise. The tinted band above it is where the promise breaks, and two of the three spend time up there.
The fixed window hits twenty per second at the eight-second mark. That spike is the boundary burst described above, happening: ten requests land just before the whole second and ten just after, each window sees a legal ten, and the service downstream takes twenty in a fifth of a second. Nothing is misconfigured. The algorithm is doing what it says.
The token bucket also goes over, at nineteen per second, and that one is on purpose. A bucket that has been idle is full, so the first burst goes straight through. That is usually what you want from an API limiter, and it is why the token bucket is the common default, but you have to know you agreed to it.
The sliding window never leaves the safe region. It peaks at exactly ten because it counts admissions in a window that really does slide with the clock, so there is no seam to exploit. It admits the fewest requests of the three, 60 of 120, and that is the trade: the strictest promise costs you the most rejected traffic and the most memory, since it keeps a log instead of a counter.
Sliding window fixes the boundary exploit by looking at the last 60 seconds from the current moment, rather than fixed 1-minute blocks. At 10:01:02, the window covers 10:00:02 to 10:01:02. It sees all 180 requests and rejects the excess.