Fixed Window Rate Limiting: Simple Counter Implementation (2026)

This is a fixed window counter implementation for rate limiting, and it’s broken because the RateLimiter component is failing to increment its internal counters, leading to requests being incorrectly allowed through.

The core issue is that the RateLimiter relies on a shared, atomic counter for each defined time window. When this counter fails to update, the system can’t accurately track request volumes. Here are the most common reasons this happens:

1. Redis Connection Issues: The most frequent culprit is a flaky connection to the Redis instance where the counters are stored. If Redis is down, unreachable, or experiencing high latency, the INCR command will fail.

   • Diagnosis: Check your Redis logs for connection errors, timeouts, or (error) messages. Use redis-cli ping from the RateLimiter service’s host to test connectivity.
   • Fix: Ensure your Redis server is running and accessible. If using a cloud provider, verify network security groups or firewall rules. For instance, if your Redis is on 10.0.0.5:6379, ensure your RateLimiter service can reach it. Restart the Redis service if necessary.
   • Why it works: Redis is the single source of truth for the counters. A stable connection allows the INCR command to atomically update the count for the current window.

2. Incorrect Redis Key Prefix: The RateLimiter uses a prefix to distinguish keys for different rate limiters. If this prefix is malformed or inconsistent, the INCR command might be targeting the wrong (or a non-existent) key, or multiple rate limiters could collide on keys.

   • Diagnosis: Examine the RateLimiter configuration file. Look for the redis_key_prefix setting.
   • Fix: Ensure the redis_key_prefix is set correctly and consistently across all instances of your RateLimiter service. For example, set redis_key_prefix: "rl:" in your configuration.
   • Why it works: A consistent prefix ensures that each rate limiter operates on its own unique set of keys in Redis, preventing interference and ensuring INCR targets the intended counter.

3. Time Synchronization Drift: Fixed window counters are highly sensitive to time. If the clock on the RateLimiter service is significantly out of sync with the clock on the Redis server, the window calculation (current_time / window_size) will be wrong, leading to INCR targeting outdated or future keys, effectively skipping the current window.

   • Diagnosis: On the RateLimiter host, run date and compare it with redis-cli --intrinsic-info | grep 'redis_version'. If the Redis server is on a different machine, run ssh redis-host 'date' and compare.
   • Fix: Configure NTP (Network Time Protocol) on all RateLimiter and Redis servers to keep their clocks synchronized. For example, ensure ntpd or chronyd is running and configured to sync with reliable time sources.
   • Why it works: Accurate time synchronization ensures that the RateLimiter correctly identifies the current time window when constructing the Redis key, allowing INCR to operate on the correct counter.

4. Redis EXPIRE Command Failing: The RateLimiter should set an expiration on the Redis keys to clean them up after the window has passed. If the EXPIRE command fails (e.g., due to Redis persistence issues or a Redis server restart before persistence), old keys might linger, and new keys might not be created correctly.

   • Diagnosis: After observing the error, check Redis for keys related to your rate limiter using redis-cli KEYS "rl:*". If you see keys that should have expired, the EXPIRE command is likely failing.
   • Fix: Ensure Redis is configured for appropriate persistence (e.g., RDB snapshots or AOF logging) and that the RateLimiter service correctly issues the EXPIRE command after the INCR. The EXPIRE command should be set to a value slightly larger than the window size, e.g., EXPIRE rl:12345 65 if the window is 60 seconds.
   • Why it works: Setting an expiration ensures that counters automatically reset for new windows, preventing stale data from affecting current rate limiting decisions.

5. Redis INCR Command Not Being Executed Atomically: While Redis INCR is atomic, the surrounding logic in the RateLimiter might not be. If multiple threads or processes within the RateLimiter service attempt to update the same counter without proper locking or if the INCR command is part of a larger, non-atomic transaction that fails mid-way, the increment might be lost.

   • Diagnosis: This is harder to diagnose externally. It often manifests as intermittent, hard-to-reproduce failures. Look for race conditions in the RateLimiter’s internal code if you have access to it.
   • Fix: Ensure the code path that calls redis-cli INCR is properly synchronized. If the RateLimiter uses a client library, verify it’s configured for atomic operations and that your application code isn’t introducing non-atomic operations around it. For example, in many Redis clients, INCR is inherently atomic. The fix would be in ensuring no other operation interferes before or after INCR within the same logical operation if the library doesn’t handle it.
   • Why it works: Guarantees that each individual increment operation is performed without interruption, ensuring the counter accurately reflects the total number of requests.

6. Redis maxmemory Policy: If your Redis instance is configured with a maxmemory limit and a volatile-lru or allkeys-lru eviction policy, and Redis runs out of memory, it might start evicting keys. If your rate limiting counters are evicted, they will effectively reset to zero, leading to incorrect allowance of requests.

   • Diagnosis: Check your Redis configuration for maxmemory and maxmemory-policy. Monitor Redis memory usage using redis-cli INFO memory.
   • Fix: Increase maxmemory on your Redis server or adjust the maxmemory-policy to something more suitable, or ensure your RateLimiter keys have appropriate expirations so they are naturally evicted. If your window is 60 seconds and you have 1000 rate limiters, and each can have up to 1000 requests, you might need a few MB for counters. For example, set maxmemory 256mb.
   • Why it works: Prevents Redis from evicting essential rate limiting counter keys, ensuring they persist for the duration of their intended window.

Once these issues are resolved, the next error you’ll likely encounter is a TOO_MANY_REQUESTS (HTTP 429) response, indicating that the rate limiting is now functioning correctly and blocking excess requests.