Rate Limiting Algorithms: Token Bucket vs Sliding Window vs Fixed Window
Compare token bucket, sliding window, fixed window, and leaky bucket rate limits by fairness, burst handling, state cost, and distributed API trade-offs.
Read guideWeb Security
Rate limiting guides
Algorithms, identifiers, distributed coordination, and response design for resource limits.
What these guides cover
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.
Risks
- Traffic bursts overwhelming a constrained dependency
- Distributed clients bypassing per-IP limits
- Boundary errors, retries, and duplicate accounting
- Limiter-store latency, partitions, and unavailable decisions
Control priorities
- Algorithm matched to fairness and burst requirements
- User, account, tenant, API key, and IP identifiers
- Coordinated distributed state and explicit failover policy
- Dry-run measurement and useful 429 responses
Recommended reading order
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.