Tensions in Practice: Simple rate accounting in tension with boundary bursts¶
One actor · an illustrative request meter
Imagine a budget of two requests per ten ticks. With fixed windows, an actor can use two just before a boundary and two just after it: each window obeys the rule, yet four requests arrive close together. A rolling ten-tick meter still counts the first pair when the second arrives. The budget number is unchanged; the memory of recent use is different.
Keep accounting simple
Maintain a small counter with a clear periodic reset.
Limit short boundary bursts
Count recent usage even when a calendar boundary has just passed.
Why these aims pull against each other
Fixed-window resets discard recent usage from the previous window. A rolling window removes that edge effect by retaining enough timing information to count across the boundary.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Fixed windows
Allow two requests in each fixed interval [0,10) and [10,20), resetting the counter at tick 10.
- What it protects
- Tracking the current interval and its count is simple.
- What it costs
- Two full budgets can be consumed close together across the boundary.
- When it fits
- Fits a service whose stated contract is per fixed interval and whose capacity tolerates that boundary burst.
Illustration note: Ticks and requests are invented arithmetic, not measurements. The graph does not claim that every fixed-window workload produces a burst.
Rolling interval
Count admissions in the trailing ten ticks and reject the tick-11 pair because the tick-9 pair still consumes the budget.
- What it protects
- This boundary-straddling attempt cannot obtain two fresh budgets.
- What it costs
- The meter must maintain more recent-use information, and clients that a fixed window would admit may be rejected.
- When it fits
- Fits a resource where the recent-interval cap matters enough to justify the tracking cost and the rejection contract.
Illustration note: This is a rolling-window count, not a token bucket or an approximate sliding counter. The example chooses rejection rather than queueing.
What this illustration does—and does not—establish
Rate Limiting: Fixed versus Sliding Window (the boundary edge effect) supplies the edge effect. The four invented arrivals make the changed membership of the accounting interval inspectable.
- Both arrangements concern one identified actor; many compliant actors can still overload a shared resource.
- A rate cap does not bound total lifetime consumption.
- The diagrams order events; their spacing does not represent measured elapsed time.
Source entries
Rate Limiting
Rate Limiting: Fixed versus Sliding Window (the boundary edge effect) supplies the conflict examined here.
Fixed versus Sliding Window (the boundary edge effect)
T4 — Fixed versus Sliding Window (the boundary edge effect). A fixed window is cheap to track but has an edge effect — an actor spending the full budget at the end of one window and the start of the next achieves twice the nominal rate across the boundary; a sliding window is smooth but costlier to maintain. The failure mode is specifying a fixed-window limit and being surprised by boundary-straddling bursts that double the effective rate exactly when the system is most loaded. Diagnostic: ask what happens at the window boundary; if doubling the rate for one boundary-spanning interval is harmful, the fixed window's edge effect is unacceptable and a sliding window (or smaller window) is required.