Sliding window rate limiting
Sliding window rate limiting maintains a rolling count of requests over the recent N seconds, updating continuously as time progresses. Unlike fixed window which resets at discrete intervals, sliding window always looks back exactly N seconds from the current moment. This eliminates the burst-at-boundary problem but requires more memory and computation to maintain the rolling count.
Formula
requests_in_window = count(timestamps > now - window_size). if requests_in_window > limit: reject_request.Why it matters in practice
Sliding window provides smoother, more predictable rate limiting behavior that cannot be gamed by timing requests at window boundaries. It's the preferred choice for APIs that need consistent protection against abuse. The trade-off is implementation complexity: you need to store timestamps for recent requests and clean up old ones. Redis with sorted sets (ZSET) is a common implementation pattern, using expiration to automatically clean up old timestamps.
Common mistakes
- •Implementing sliding window with in-memory storage in a distributed system — each server sees only its slice of traffic, allowing coordinated attacks.
- •Not cleaning up old timestamps efficiently — this can cause memory leaks in long-running services.
- •Using sliding window for very high request rates (10k+ RPS) — the overhead of maintaining the rolling count can become a bottleneck.