Design a Distributed Rate Limiter

It sounds small and hides a real distributed-systems problem. The job is simple to state. For every incoming request, decide in a millisecond or two whether to allow it or reject it. On a reject, return HTTP 429 with a Retry-After header so a well-behaved client knows to back off. The limiter exists to protect the API from overload and to keep one merchant's traffic burst from starving everyone else. The trap is the word "distributed." The decision runs on a fleet of many API servers, so the count of how much a merchant has used cannot live on one server. It has to be shared, and sharing a fast-changing counter across a fleet is where the design gets interesting.

Frame the goal before drawing anything. Abuse detection, fraud scoring, and billing all live elsewhere. What this system does is smooth load. A merchant gets a steady rate of requests plus some room to burst. Past that we shed their excess, so the shared API stays healthy for everyone behind it. The limiter has to be far cheaper than the work it guards, since it runs on the hot path of every single call. And it has to honor the limit fleet-wide even though no single server sees all the traffic.

The Stripe angle

Stripe literally published this design, so the round is really checking whether you can rediscover it. Stripe's engineering blog "Scaling your API with rate limiters" lays out four kinds of limiter working together and names token bucket in Redis as the core mechanism. Get to token bucket and shared Redis state on your own and you show you have run an API in production. It also ties straight to the idempotency story: a 429 is a retryable response, so a client that gets one backs off and retries under the same idempotency key, never a fresh charge. Connect the limiter to safe retries and you have shown why Stripe cares about both at once.