Fixed window counters

A car park with five spaces and a barrier. Every thirty seconds the barrier resets and the spaces are free again.

That's a fixed window counter, the simplest rate limiting algorithm there is. Count requests inside a window of fixed length, refuse anything past the limit, and reset the count when the window ends.

Watching one window fill

A limit of five requests per thirty-second window:

Time	What arrives	Count	Outcome
0s	1 request	1	Accepted
5s	2 requests	3	Accepted
15s	2 requests	5	Accepted, and the barrier comes down
25s	1 request	5	Rejected, the window is full
30s	Window 2 opens	0	The count resets

The state involved is two values: where you are in the window, and the count so far. Nothing carries over from the window that ended.

That simplicity is the entire appeal. Cheap to store, cheap to check, and hard to get confused about.

JunoWatching one window fill Notice the request at 25 seconds. It's refused with five seconds to go, and if it had waited six it would have sailed through.

That's the algorithm being blunt rather than unfair. It has no notion of nearly, only of inside this window or not.

JunoWatching one window fill "Nothing is remembered about the previous window" is what makes this cheap to run. One counter and one timestamp per client, and a reset that throws the old value away.

Compare that with keeping a timestamp for every request, which is what the next algorithm needs. The storage difference is the tradeoff the whole comparison turns on.

JunoWatching one window fill There's a second problem alongside the burst, and it's the mirror image: the drought. Five requests arriving in the first second of a window leave twenty-nine seconds where a legitimate client is refused despite the service being idle.

Fixed windows are therefore rough on bursty-but-reasonable traffic, which is most real traffic. A page loading six resources at once spends a whole window's budget instantly.

Also worth deciding whether windows are aligned to the clock or to a client's first request. Clock-aligned windows mean every client's window resets at the same instant, which synchronises everyone's retries into one spike.

The boundary burst

Now watch two consecutive windows, with the same limit of five per thirty seconds:

Time	Window	Requests	Running count
50s	2	2	4
55s	2	2	6, so 5 accepted
60s	3 opens	2	2

Look at the clock rather than the windows. Between 50 and 60 seconds, seven requests were accepted.

The limit was five per thirty seconds, and seven arrived in ten.

Nothing malfunctioned. Requests at the end of window two and the start of window three are in different windows, so neither count ever exceeded five. The algorithm did exactly what it was told.

That's the window boundary issue, and it's the defining weakness of this approach. In the worst case a client sends the full limit immediately before a reset and the full limit immediately after, putting twice the limit through in a moment.

JunoThe boundary burst The trick is where you're standing. Inside each window everything is correct and under the limit.

Step back and look at a stretch of clock time crossing the boundary, and the limit was never really enforced there at all.

JunoThe boundary burst Worth putting a number on it: the worst case is twice your limit in an instant, so size the limit for that. If your service can survive 200 requests in a burst, a fixed window limit of 100 is defensible.

An attacker who knows your window length can hit that boundary deliberately, and window length is simple to infer by watching when the reset happens.

JunoThe boundary burst This is exactly reproducible rather than theoretical. Measured against a fixed window limit of 100, sending across a boundary allows 200 requests through.

The sliding window log allows 100 and the sliding window counter 101, which is the comparison the next chapters build on.

The reason to keep using fixed windows anyway is the cost profile: one integer and one timestamp per client, incremented atomically. At the scale where rate limiting matters most, that difference in storage and coordination is not small.

The usual production answer is a fixed window sized so twice the limit is survivable, with something more precise on the few endpoints where a burst does real damage.

Try it

An API allows 10 requests per 60-second window, clock-aligned so windows start on the minute.

1. A client sends 10 requests at 12:00:59 and 10 more at 12:01:01. How many are accepted, and is the limit broken?
2. A client sends all 10 at 12:00:00. What happens to their request at 12:00:30?
3. You need to guarantee no client ever gets more than 10 requests in any 60-second stretch. Can a fixed window do it?

Compare your answers

1. All 20 are accepted, and no rule was broken. The first ten fall in the 12:00 window and the second ten in 12:01, so neither count passed 10.

Twenty requests arrived in two seconds. That's the boundary burst, and it took nothing cleverer than noticing when the minute turns.

2. Rejected. The window is full and has thirty seconds left to run. The service is completely idle and the client still waits, which is the drought that comes with the burst.

3. No. Not with a fixed window, at any limit. Any stretch of clock that crosses a boundary can carry up to twice the limit, and that's a property of dividing time into fixed blocks rather than a tuning problem.

Getting that guarantee means measuring against a window that moves with the request instead of a block on a calendar, which is the next chapter.

Where this goes next

Fixed windows are cheap, simple, and wrong by up to a factor of two at the boundary. Whether that matters depends on what the endpoint does.

Before fixing it, it's worth building one. Building a rate limiter turns this algorithm into working Express middleware, with the headers a client needs to behave well.