Definition
A Fixed Window Counter divides time into discrete intervals (windows) and counts requests within each. When the count exceeds the limit, requests are rejected until the next window begins.
The Hourly Train Schedule Analogy
Imagine a train station allowing 100 passengers per hour. At the top of each hour, the count resets. If 100 passengers board by 2:45 PM, everyone else waits until 3:00 PM. This is fixed window rate limiting: simple boundaries, predictable resets, but potentially frustrating for users arriving just after capacity is reached.
How Fixed Window Works
Divide time into fixed intervals (1 second, 1 minute, 1 hour). For each unique identifier (user, IP, API key), maintain a counter. When a request arrives, check the current window counter. If under limit, increment and allow. If at or over limit, reject with 429. When the window ends, reset to zero. With Redis, use a key like user:123:minute:202401151430 with INCR and TTL.
The Boundary Problem
Fixed windows have a critical flaw at boundaries. With a limit of 100/minute, a user can send 100 requests at 2:59:59 and 100 at 3:00:01. That is 200 requests in 2 seconds while staying within limits for each window. This burst can overwhelm downstream systems even though no single minute exceeds 100.
When to Use Fixed Window
Fixed window works when: boundaries are acceptable (billing cycles, daily limits), simplicity is critical (embedded systems, edge computing), and exact per window enforcement matters. For API rate limiting where burst protection is important, sliding windows or token buckets are better. Fixed window is often a stepping stone before implementing more sophisticated algorithms.
Implementation Costs
Memory: O(1) per user per window (just a counter). Processing: O(1) per request. Storage expires with TTL. This is why fixed window is often the first rate limiting algorithm: minimal overhead, easy to understand, good enough for many use cases.
✓Memory efficient with O(1) space per key per window. With 10 million keys and 8 byte counters, just 160 MB for two active windows compared to sliding log which needs gigabytes.
✓Boundary spike vulnerability allows clients to send 2N requests in short bursts by splitting across window edges. A 100 req/min limit can become 200 req/sec at boundaries.
✓Reddit API uses approximately 60 requests per minute which clients can game at boundaries. Amazon API Gateway avoids this by using token buckets instead of pure fixed windows.
✓Update and enforcement operations are O(1) with no timestamp storage required. Simply compute window_id = floor(current_time / window_size) and increment counter[key][window_id].
✓Ideal for billing, compliance, and batch reporting where deterministic cutoffs matter and business logic aligns with window boundaries. Poor choice when burst control is critical.
✓Clock skew of even 100 milliseconds across distributed enforcers can cause double counting or dropped events at window transitions in multi node deployments.
1Production implementation: key = "user:12345", window_size = 60 seconds. At timestamp 1699123459 (second 59), window_id = floor(1699123459/60) = 28318724. Increment counter["user:12345"][28318724]. At timestamp 1699123460 (second 0 of next minute), window_id = 28318725, a new counter starts.
2Reddit rate limiting: 60 requests per minute per OAuth client. Client sends 60 requests at 00:00:59.5 (all counted in window 0), then 60 more at 00:01:00.5 (all counted in window 1). Server sees 120 requests in 1 second but both windows show 60, within limits.
3Memory calculation: 10 million active users, 2 windows (current and previous), 8 bytes per counter, 8 bytes per key hash. Total: 10,000,000 × 2 × 16 bytes = 320 MB plus hash table overhead (typically 1.5 to 2 times for 480 to 640 MB).