Rate Limiting

Limit demand at the identity and resource that matter#

One client can send 50,000 requests per second to an API built for ordinary traffic. A rate limiter protects fairness, abuse boundaries, infrastructure, downstream dependencies, and product quotas. First choose the dimension: user, IP, API key, tenant, endpoint, global traffic, or a combination.

Algorithms encode burst policy#

Fixed window

user:42:2026-08-14T12:30 → 73 of 100 requests

One counter per calendar bucket is simple, but traffic can burst at the end of one window and start of the next.

Sliding window

Count the actual preceding interval. Boundary behavior improves, while exact logs or approximations require more state and computation.

Token bucket

Tokens refill at a sustained rate up to a capacity. Requests consume tokens, allowing a bounded burst while limiting the long-run rate.

Leaky bucket

Model work leaving at a controlled rate. It emphasizes smoothing output, while token bucket emphasizes permitting bounded bursts. Implementations vary, so describe the behavior you need before naming the algorithm.

Local counters undercount a global limit#

If three API servers each enforce 100 requests per minute independently, a client routed across them can exceed an intended global 100. Shared counters, partitioned ownership, local allowances plus reconciliation, or edge enforcement provide different trade-offs.

Return a useful rejection and design limiter failure#

429 Too Many Requests communicates rate limiting. The response can explain the condition and may include retry timing; clients should back off rather than create a retry storm.

Plan for an unavailable counter store, hot identities, partitions, clock/window errors, global contention, and synchronized retries. Fail-open versus fail-closed depends on what is protected: login-abuse controls and a low-risk recommendation endpoint can make different choices.