Sliding Window
A rate limiting algorithm that tracks requests in a rolling time window. More accurate than fixed windows because it smooths out spikes at window boundaries.
What is Sliding Window?
In short
A sliding window is a rate limiting algorithm that counts requests over a continuously moving time interval, such as "the last 60 seconds counting backward from right now," instead of resetting a counter at fixed clock boundaries. This smooths out the traffic bursts that fixed-window limiters allow at the edges of each window.
What it is
A rate limiter decides whether to allow or reject an incoming request based on how many requests a client has already made. The sliding window is one of the most common algorithms for making that decision, and it exists to fix a specific weakness in the simpler fixed-window approach.
A fixed window counts requests in discrete buckets tied to the clock: 12:00:00 to 12:00:59 is one bucket, 12:01:00 to 12:01:59 is the next. The problem is the boundary. If your limit is 100 requests per minute, a client can send 100 requests at 12:00:59 and another 100 at 12:01:00, which is 200 requests in two seconds, because the counter reset in between.
A sliding window removes those hard reset points. The window is always measured relative to the current moment. At 12:00:30 the window covers 11:59:30 to 12:00:30. One millisecond later it covers a range shifted forward by one millisecond. There is no point where the count suddenly drops to zero, so a client cannot exploit the boundary.
How it works under the hood
There are two main implementations. The sliding window log keeps a timestamp for every request, usually in a sorted structure like a Redis sorted set. On each new request you delete all timestamps older than the window, count what remains, and allow the request only if the count is below the limit. This is exact, but storing one entry per request is expensive at high volume.
The sliding window counter is the practical compromise most production systems use. It keeps just two numbers: the count for the current fixed window and the count for the previous one. It then estimates the rolling count with a weighted formula. If you are 25 percent into the current minute, the estimate is current_count plus previous_count times 0.75. So with 80 requests last minute and 20 this minute, the estimate is 20 + 80 times 0.75 = 80.
That counter approach needs only two integers per client instead of one timestamp per request, which is why it scales. The trade-off is that it assumes requests in the previous window were spread evenly, so the estimate can be slightly off, but in practice the error is small and it never allows the 2x boundary burst that fixed windows do.
When to use it and the trade-offs
Use a sliding window when you need fairly accurate per-client limits and care about preventing edge-of-window bursts: public APIs, login endpoints protecting against credential stuffing, and any quota you advertise to customers as a hard number. It gives much smoother enforcement than fixed windows for very little extra cost.
The sliding window counter trades a tiny amount of accuracy for a large amount of memory savings, which is usually the right call. The sliding window log trades memory for exactness, so reserve it for low-volume, high-stakes limits where being off by a few requests matters.
If you instead need to allow short controlled bursts above the steady rate, a token bucket is often the better fit because it is designed around burst capacity. Sliding window is about smoothing, token bucket is about bursting. Many real systems run both: a token bucket for burst shaping and a sliding window for the absolute ceiling.
A concrete real-world example
Imagine an API that allows 100 requests per minute per API key, backed by Redis. Each key has two counters with one-minute expiry. A request arrives 45 seconds into the current minute. The service reads the previous minute count, say 90, and the current count, say 30.
It computes the weighted estimate: 30 plus 90 times the fraction of the previous window still inside the rolling view, which is 15 seconds out of 60, or 0.25. That gives 30 + 90 times 0.25 = 52.5, rounded to 52. Since 52 is below 100, the request is allowed and the current counter increments to 31.
Compare that to fixed windows, where this same client could have fired 100 requests in the last few seconds of the previous minute and 100 more now without being blocked. The sliding window's estimate folds the recent past into the decision, so the burst is caught and throttled.
Where it is used in production
Cloudflare
Uses a sliding window counter for its rate limiting product, blending the current and previous fixed-window counts to approximate the rolling rate cheaply at edge scale.
Redis
The common backing store for sliding windows; sorted sets implement the exact log variant and INCR with EXPIRE implements the counter variant.
Kong
The API gateway ships a sliding-window rate limiting plugin so teams can enforce smooth per-consumer quotas without writing their own counter logic.
GitHub API
Enforces hourly request quotas per token with rolling-window style accounting and returns remaining-quota and reset headers on every response.
Frequently asked questions
- What is the difference between a sliding window and a fixed window?
- A fixed window resets its counter at clock boundaries like every minute, which lets a client burst up to 2x the limit by hitting the seconds just before and after a reset. A sliding window measures the count relative to the current moment, so there is no reset point to exploit and bursts are smoothed out.
- What is the difference between sliding window log and sliding window counter?
- The log stores a timestamp for every single request and gives an exact count, but uses a lot of memory at high traffic. The counter keeps only the current and previous window counts and estimates the rolling rate with a weighted formula, using far less memory at the cost of small approximation error.
- Is sliding window better than token bucket?
- Neither is strictly better; they solve different problems. Sliding window smooths traffic to a steady ceiling and prevents boundary bursts. Token bucket is built to allow controlled bursts above the average rate. Use token bucket when short bursts are acceptable, sliding window when you want a firm smooth limit.
- How accurate is the sliding window counter?
- It assumes the previous window's requests were spread evenly over time, so its estimate can be slightly high or low if traffic was bunched. In practice the error is a few percent, and unlike fixed windows it never permits the full 2x boundary burst, so it is accurate enough for almost all API rate limits.
- Why is Redis commonly used for sliding window rate limiting?
- Redis is fast, in-memory, and shared across all your servers, so every instance sees the same counts. Sorted sets cleanly implement the exact log variant, while INCR plus EXPIRE on two per-client keys implements the cheaper counter variant, and its single-threaded execution avoids race conditions on the counters.
Learn Sliding Window hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Sliding Window as part of a larger topic.
Sliding Window
Rate limit with a moving time window, smoother than fixed windows and more accurate
intermediate · api design protocols
Sliding Windows
Windows that slide with every event, continuous recalculation over the most recent N events or T time
advanced · stream batch processing
Rate Limiting for Resilience
Protect services from abuse and overload, token bucket, sliding window, and distributed rate limiting
advanced · reliability resilience
Design a Rate Limiter
Design a distributed rate limiting system - token bucket, sliding window, and protecting services at massive scale
capstone · capstone
See also
Related glossary terms you might want to look up next.
Rate Limiting
Controlling how many requests a client can make in a given time window. Protects your API from abuse and ensures fair usage.
Token Bucket
A rate limiting algorithm where tokens are added to a bucket at a fixed rate. Each request consumes a token; requests are rejected when the bucket is empty. Allows short bursts.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
OAuth
An authorization framework that lets users grant third-party apps limited access to their accounts without sharing passwords. Powers 'Sign in with Google.'
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
SSL/TLS
Cryptographic protocols that encrypt data in transit between client and server. TLS is the modern successor to SSL. The 'S' in HTTPS.