Rate-limiting algorithms compared: token bucket, leaky bucket, sliding window, and fixed window
Token bucket, leaky bucket, sliding window, or fixed window?
Read guideWeb Security
Algorithms, identifiers, distributed coordination, and response design for resource limits.
Rate limiting controls how frequently an identity may consume a constrained operation or resource. A complete policy combines an algorithm, capacity and refill rules, a stable identifier, distributed state, response behavior, and an explicit failure mode. Fixed windows offer simple accounting but permit boundary bursts; sliding approaches improve recent-history fairness at different memory costs; token buckets permit controlled bursts; and leaky buckets shape output at a steady rate. The implementation must also handle shared networks, rotating attackers, retries, hot keys, store outages, and client guidance through HTTP 429 and retry information. Limits should protect availability without turning shared infrastructure into an avoidable denial of service.
Use the rate limiting guide to compare algorithms first, then choose identifiers and distributed topology based on the protected resource. Finish with response semantics, observability, boundary tests, and outage behavior before enforcing limits.
Token bucket, leaky bucket, sliding window, or fixed window?
Read guideTell a denial-of-service flood from a large customer by identity, not volume.
Read guideRate limiting controls how many actions an identity can perform in a period.
Read guideChange Arcjet rate limits at runtime without redeploying.
Read guide