We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Security Architecture
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Sliding Window across a run of lessons, not one page. These 4 alone are about 119 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
Rate limit with a moving time window, smoother than fixed windows and more accurate.
Windows that slide with every event, continuous recalculation over the most recent N events or T time.
Protect services from abuse and overload, token bucket, sliding window, and distributed rate limiting.
Design a distributed rate limiting system - token bucket, sliding window, and protecting services at massive scale.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Sliding Windowpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Sliding Windows
Windows that slide with every event, continuous recalculation over the most recent N events or T time
Rate Limiting for Resilience
Protect services from abuse and overload, token bucket, sliding window, and distributed rate limiting
Design a Rate Limiter
Design a distributed rate limiting system - token bucket, sliding window, and protecting services at massive scale
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.
This page explains the idea. The "Sliding Window" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Sliding Window lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Sliding Window in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
