Fixed Window vs Sliding Window Rate Limiting: What Is the Difference?
Compare fixed window and sliding window rate limiting, the boundary-burst flaw, and the sliding window counter approximation.
Expected Interview Answer
Fixed window rate limiting counts requests in discrete, non-overlapping time buckets like “per calendar minute,” while sliding window rate limiting evaluates the limit over a continuously moving time span, which closes the boundary-burst loophole fixed windows allow.
A fixed window counter resets to zero at the start of every new window, which is simple and cheap but has a well-known flaw: a client can send the full quota in the last moment of one window and the full quota again in the first moment of the next window, resulting in nearly double the intended rate within a short real-time span even though each window individually stayed within limits. A sliding window log fixes this by storing the exact timestamp of every request and counting how many fall within the trailing time span ending “now,” giving perfect accuracy at the cost of memory proportional to request volume. A sliding window counter is the practical middle ground: it keeps only two fixed-window counters (current and previous) and estimates the sliding count by weighting the previous window’s count by how much of it still overlaps the trailing window, giving close-to-exact accuracy with the storage cost of just two counters per key, which is why it is the common production default.
- Sliding window eliminates the boundary-burst exploit inherent in naive fixed windows
- Sliding window counter achieves near-exact accuracy at low, constant memory cost per key
- Fixed window remains the simplest and cheapest option when boundary bursts are acceptable
- Choosing the right variant lets teams balance accuracy, memory, and implementation complexity for their scale
AI Mentor Explanation
Fixed window rate limiting is like capping deliveries strictly by the clock-face over, so a team could theoretically bowl six balls in the final seconds of one over and six more the instant the next over is called, briefly doubling the real-time bowling rate around that boundary. Sliding window rate limiting instead evaluates any rolling six-ball stretch continuously, regardless of where the official over lines fall, so that clustering trick is caught immediately. The fixed approach is simpler to score but has a real loophole at over breaks, while the sliding approach is more work to track but reflects the true, continuous pace of play. That is exactly the trade-off between the two rate-limiting strategies.
Step-by-Step Explanation
Step 1
Fixed window: reset per interval
A counter resets to zero at the start of each discrete time window (e.g., every minute) and rejects once the limit is hit.
Step 2
Identify the boundary flaw
A client can send the full quota at the end of one window and again at the start of the next, doubling the effective real-time burst.
Step 3
Sliding window log: exact fix
Store every request timestamp and count how many fall within the trailing time span ending now — perfectly accurate but memory-heavy.
Step 4
Sliding window counter: practical fix
Keep just current and previous window counts, weighting the previous count by remaining overlap — near-exact accuracy at low memory cost.
What Interviewer Expects
- Explains the fixed window boundary-burst problem with a concrete example
- Describes sliding window log’s exact timestamp tracking and its memory cost
- Describes sliding window counter’s weighted-approximation approach as the practical default
- Can articulate the accuracy vs. memory/complexity trade-off across all three
Common Mistakes
- Not being able to explain concretely why fixed window allows near-double bursts
- Confusing sliding window log with sliding window counter (very different memory costs)
- Claiming fixed window is always wrong — it is fine when boundary bursts are acceptable
- Forgetting that sliding window log accuracy comes at real, non-trivial storage cost
Best Answer (HR Friendly)
“Fixed window rate limiting just counts requests inside a clock-aligned time block, like each calendar minute, and resets to zero at the boundary. The catch is someone can sneak in a burst right at the edge of two blocks and briefly get almost double the allowed rate. Sliding window rate limiting fixes that by always looking at the last full time span ending right now, no matter where the clock sits, so that edge-case burst is caught and the limit actually holds.”
Code Example
rateLimiters:
fixedWindow:
strategy: fixed-window
limit: 100
windowSeconds: 60
note: "Simple, cheap, but allows near-2x burst at window boundary"
slidingWindowLog:
strategy: sliding-window-log
limit: 100
windowSeconds: 60
storage: per-request-timestamp
note: "Exact accuracy, memory scales with request volume"
slidingWindowCounter:
strategy: sliding-window-counter
limit: 100
windowSeconds: 60
storage: current-and-previous-counter
note: "Near-exact accuracy, constant low memory per key -- production default"Follow-up Questions
- Can you walk through a concrete example where fixed window allows almost double the intended rate?
- How does the sliding window counter’s weighting formula work mathematically?
- When is a naive fixed window still an acceptable production choice?
- How would you implement a sliding window counter consistently across multiple distributed rate limiter nodes?
MCQ Practice
1. What is the core flaw of a naive fixed window rate limiter?
A client can exhaust the quota at the end of one window and immediately again at the start of the next, doubling the effective real-time rate.
2. What does a sliding window log store to achieve exact accuracy?
Sliding window log tracks every request’s timestamp so it can count exactly how many fall within the trailing time span, at the cost of memory.
3. How does a sliding window counter approximate sliding-window accuracy cheaply?
It keeps just two counters (current and previous window) and blends them by overlap proportion, giving near-exact results at low memory cost.
Flash Cards
Fixed window flaw? — Allows near-double the limit in a burst spanning two adjacent window boundaries.
Sliding window log? — Stores every request timestamp for exact accuracy; memory scales with request volume.
Sliding window counter? — Approximates sliding accuracy using just current and previous window counts, weighted by overlap.
Why is sliding window counter the common production default? — It gives near-exact accuracy at the low, constant memory cost of two counters per key.