Sliding Window Rate Limiting Guide
Sliding window vs fixed window rate limiting. Redis sorted set implementation, precision trade-offs, and when to use each.
High Precision: Sliding Window Rate Limiting
The Sliding Window rate limiter provides high precision by evaluating request counts over a rolling time window, eliminating the boundary reset bursts common in fixed window algorithms.
1. The Fixed Window Boundary Problem
A fixed window rate limiter resets its counter at fixed intervals (e.g. at the start of each minute). Under this model, a client can execute their entire limit at the end of the first minute and another full limit at the start of the second minute. This creates a double-limit burst at the boundary, potentially overloading your database servers.
2. The Sliding Window Solution
A sliding window tracks the exact timestamps of every request. When a request arrives, the limiter:
- Removes expired timestamps: Deletes all records older than
now - window_size. - Counts active entries: Counts the remaining timestamps in the active window.
- Evaluates limits: If the count is below the limit, it adds the new request timestamp to the set and allows the request.
3. Redis Sorted Set (ZSET) Implementation
In Redis, this is implemented using a Sorted Set (ZSET) where the member is a unique UUID and the score is the request timestamp in milliseconds:
`lua
local key = KEYS[1]
local window_size = tonumber(ARGV[1]) -- in seconds
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local member = ARGV[4]
local window_start = now - (window_size * 1000)
redis.call('ZREMRANGEBYSCORE', key, 0, window_start)
local count = redis.call('ZCARD', key)
if count < limit then
redis.call('ZADD', key, now, member)
redis.call('EXPIRE', key, window_size + 1)
return 1 -- Allowed
end
return 0 -- Blocked
`
4. Memory Overhead Trades
- Precision: Guaranteed strict enforcement with zero boundary burst risk.
- Memory Cost: Storing unique timestamps for every request consumes significantly more Redis memory than simple token bucket hashes. High-throughput APIs should weigh this memory cost before deploying sliding window rules.
Next Steps
Ready to protect your API with production-grade rate limiting? Here is the recommended path for Sliding Window Rate Limiting Guide:
- Create a free account at [limityourapi.tech/login](/login) — no credit card required for the Hobby tier
- Generate an API key in the dashboard under API Keys
- Install the SDK: Run
npm install limityourapiand follow the [Node.js](/sdk/nodejs) guide - Follow the quick start guide at [/quickstart](/quickstart) for a 2-minute integration
- Configure rules in the dashboard for your highest-risk endpoints first
- Monitor analytics to tune limits based on real traffic patterns
Questions? Read the [documentation](/docs) or explore the [rate limiting education hub](/learn) for deep technical guides on algorithms, architecture, and production patterns.
Frequently Asked Questions
Is sliding window memory-efficient?
No. Storing unique timestamps for every request in a Redis Sorted Set consumes significantly more memory than the token bucket, which only tracks a single hash.
What is API rate limiting?
API rate limiting controls how many requests a client can make in a given time window. It protects backends from abuse, ensures fair usage across tenants, and prevents cost overruns from traffic spikes or malicious bots.
Why use Redis for rate limiting?
Redis provides sub-millisecond latency, atomic operations via Lua scripts, and horizontal scalability. Centralized state ensures consistent limits across distributed application servers.
How fast is LimitYourAPI?
LimitYourAPI delivers rate limit decisions in under 15ms globally using atomic Redis Lua scripts. This is fast enough for inline middleware without adding perceptible latency to API responses.
Does LimitYourAPI support token bucket and sliding window?
Yes. LimitYourAPI supports token bucket, sliding window, fixed window, and cost-aware algorithms. You can configure per-route strategies without changing infrastructure.