Build a distributed rate limiter: cap how many requests a given key — an API key, a user id, an IP — may make in a window, and enforce that cap across a whole fleet of enforcer instances, on the synchronous path of every request, in well under a millisecond, without ever becoming the outage you were trying to prevent.

The one-sentence version ("count requests in Redis, reject over the limit") is right and useless. The entire problem is the gap between a global invariant ("key X ≤ R req/s") and the local vantage points that must enforce it — 200 enforcer pods, each seeing only a slice of X's traffic. Close that gap naively and a client fans out across your fleet and gets 200× the limit; close it with a single shared counter and you've put a network round trip (and a single point of failure) on every request. This problem is a distributed-consistency problem wearing a counter's clothes.

We hold everything else fixed and go deep on that core: the token-bucket algorithm as an atomic Redis Lua script, a central-authoritative counter with a per-instance fail-open fallback, and the four tensions that define the space — accuracy vs latency vs availability, and what you do when the store dies.