Twice in the same week last quarter, our YouTube Data API quota hit zero before 09:00 UTC, and the trending feeds for half our regions went stale for the rest of the day. I run TrendVidStream, a global video streaming discovery site that ingests trending-video data for 8 regions on a cron schedule, and the culprit was not traffic growth. It was our rate limiter. A fixed-window counter let two full bursts of API calls through within seconds of each other whenever a window boundary lined up with the cron schedule — and with 8 regional fetch jobs firing at staggered offsets, boundaries lined up far more often than intuition suggested they would.
This post walks through how we replaced that fixed-window counter with a sliding window log in Redis: the data model, the Lua script that makes it atomic, weighted costs for APIs where one call can be 100x more expensive than another, and the failure modes we hit running it across a multi-region ingestion pipeline. The stack is PHP 8.4 talking to Redis through phpredis, with a Python harness for verifying boundary behavior, but every part of the design transfers to any language with a Redis client.
Why the Fixed Window Failed Us
The original limiter was the one everybody writes first, because it is three lines of Redis and it mostly works:
