STANDARDwalkthrough
Sliding Window Log
We need exact request counts, not approximations, for a high-value payment API where even one extra request could cause a duplicate charge. The constraint: approximate algorithms like sliding window counter have a 0.003% error rate, and for financial transactions that is unacceptable.
To check if a user exceeds the limit, we run ZRANGEBYSCORE to count entries within the last window (say 60 seconds), remove expired entries with ZREMRANGEBYSCORE, and compare the count against the threshold. The result is mathematically exact: no boundary bursts, no approximation errors.
“The sliding window log stores a timestamp for every single request in a Redis Sorted Set, with the score set to the request timestamp.”
But precision has a cost we must quantify. At 500 requests per hour per user, each entry is roughly 24 bytes (timestamp + member).
That is 12 KB per user per hour window. Implication: scale to 1 million concurrent users and we need 12 GB of Redis memory for rate limiting state alone, which exceeds the memory of a single Redis instance (typical max 6-8 GB usable).
We chose sliding window log (not sliding window counter) only for low-volume, high-value endpoints like payment APIs where exact enforcement justifies the memory cost. Trade-off: we gave up memory efficiency for mathematical precision. Discord considered this approach for per-channel message rate limits but moved to sliding window counters because the memory overhead was unsustainable at their scale of 15 million concurrent users.
Formula & tradeoffs
Formula
Related concepts