Research paper: Overshoot, Retries and Clocks: An Empirical Study of Redis-Based Rate Limiting Under Concurrency · code and data · DOI 10.5281/zenodo.23467402

I build rate limiting for a living, and most advice about Redis limiters says the same three things: don't race, beware fixed windows, use Lua. All true, but I couldn't find anyone who had measured how big each problem is. So I did: eight implementations, four experiments, 3,853 trials, and every number generated from the raw data. The full paper is here ; this is the short version.

The race has a formula

The classic bug is GET , compare, INCR . Two workers read 99, both see room, both increment. With 64 concurrent workers and a limit of 100, it let through 128.7 requests on average, 29% more than the limit, and 137 in the worst trial.

The surprise came with network delay. Once round trips are long, the workers fall into lockstep: each wave reads the same value and increments together, so the counter grows in steps of the worker count.…