Overshoot, Retries and Clocks: An Empirical Study of Redis-Based Rate Limiting Under Concurrency
- 1Independent Researcher
Abstract
Rate limiters that share state through Redis are everywhere, and the guidance for building them warns, qualitatively, about races and burst behaviour. We measure those hazards. We implement eight common strategies (check-then-act, increment-then-check, optimistic WATCH/MULTI transactions with two retry budgets, and Lua scripts for fixed windows, token buckets, sliding-window logs and sliding-window counters) and evaluate them in 3,853 trials across concurrency (1 to 64 workers), network delay (round-trip times of 0.04 to 6.73 ms), adversarial and random arrival patterns, and clock skew. Under concurrency, every atomic strategy admitted exactly the limit in all of its trials. Check-then-act over-admitted at every concurrency level above one, by 29% on average with 64 workers, and under network delay its error follows a simple lockstep model, c*ceil(L/c) - L. Optimistic transactions avoided over-admission but, with a 10-retry budget, refused up to 42% of the capacity the limit promised, and under contention ran 12 to 30 times slower than a Lua script on the same key. Even with atomic decisions, fixed windows and token buckets configured as L per W admitted twice the limit within one window, and the sliding-window counter up to 1.66x; only the sliding-window log was exact. A token bucket fed timestamps by its callers admitted only 16% of its configured rate near the limit at 1 s of skew, while the same bucket on Redis's clock stayed exact. We turn the results into five rules for building limiters and release the harness, raw data and analysis.
Related
- The IACOB project XIX. Revisiting massive-star evolution with empirical TAMS constraints: updated models, overshoot calibration, and the population of blue supergiants
- Structured output retries: Pydantic vs raw JSON mode, verify before commit
- Discord bot rate limits: check global and per-route buckets before webhook retries
- Concurrency aware artificial intelligence for real-time intrusion detection in software-defined networks
- Low-overshoot control method for tennis trainer based on active disturbance rejection control
BibTeX
@misc{suthar2026overshoot,
title = {{Overshoot, Retries and Clocks: An Empirical Study of Redis-Based Rate Limiting Under Concurrency}},
author = {Yash Suthar},
howpublished = {Zenodo},
year = {2026},
month = oct,
doi = {10.5281/zenodo.23467402},
url = {https://zenodo.org/records/23467402},
note = {CC BY 4.0},
}
RIS
TY - UNPB
TI - Overshoot, Retries and Clocks: An Empirical Study of Redis-Based Rate Limiting Under Concurrency
AU - Yash Suthar
PY - 2026
DA - 2026/10/18
PB - Zenodo
DO - 10.5281/zenodo.23467402
UR - https://zenodo.org/records/23467402
AB - Rate limiters that share state through Redis are everywhere, and the guidance for building them warns, qualitatively, about races and burst behaviour. We measure those hazards. We implement eight common strategies (check-then-act, increment-then-check, optimistic WATCH/MULTI transactions with two retry budgets, and Lua scripts for fixed windows, token buckets, sliding-window logs and sliding-window counters) and evaluate them in 3,853 trials across concurrency (1 to 64 workers), network delay (round-trip times of 0.04 to 6.73 ms), adversarial and random arrival patterns, and clock skew. Under concurrency, every atomic strategy admitted exactly the limit in all of its trials. Check-then-act over-admitted at every concurrency level above one, by 29% on average with 64 workers, and under network delay its error follows a simple lockstep model, c*ceil(L/c) - L. Optimistic transactions avoided over-admission but, with a 10-retry budget, refused up to 42% of the capacity the limit promised, and under contention ran 12 to 30 times slower than a Lua script on the same key. Even with atomic decisions, fixed windows and token buckets configured as L per W admitted twice the limit within one window, and the sliding-window counter up to 1.66x; only the sliding-window log was exact. A token bucket fed timestamps by its callers admitted only 16% of its configured rate near the limit at 1 s of skew, while the same bucket on Redis's clock stayed exact. We turn the results into five rules for building limiters and release the harness, raw data and analysis.
ER -