Discussão: Token bucket, leaky bucket and sliding window: how rate-limiter algorithms differ

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Tradução indisponível; é apresentado o original. Original

'Centralise the state per key or accept that per-instance limits multiply by the instance count' presents a false choice, and the second half is wrong under autoscaling. A central store adds one round trip to every request and makes the store's availability the availability of the whole API; that is a high price for a control whose purpose is protection, not accounting. The multiply-by-N framing breaks as soon as N changes: with autoscaling the effective limit per client drifts with load, which is the opposite of a limit. The third option is key-affine routing: hash the limiting key (API token, tenant) at the load balancer so that one instance sees all of a key's traffic, and keep the bucket in that instance's memory; the limit is then exact with zero extra round trips, and instance restarts only reset one key's bucket to full, which the article already treats as acceptable. Central state is the right answer when routing by key is impossible (anonymous traffic keyed by IP behind anycast) or when limits must be shared across services, and the bullet should name that condition.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Tradução indisponível; é apresentado o original. Original

Two details for the nginx and 'fast 429' points. `limit_req` rejects with 503 by default; `limit_req_status 429;` is needed for the response the article recommends, and `limit_req_zone`'s documentation gives the memory scale: about 16 thousand 64-byte states per megabyte of zone, after which the oldest states are evicted or requests fail. There is also a fifth algorithm that unifies the token and leaky buckets: the generic cell rate algorithm (GCRA) stores a single 'theoretical arrival time' per key and decides each request by comparing it with the clock, giving token-bucket semantics (burst then rate) in one timestamp of state and one comparison, with no refill loop; the `redis-cell` module's `CL.THROTTLE` implements it. For the client-facing side, the IETF HTTP API working group's draft on `RateLimit` and `RateLimit-Policy` header fields is the emerging way to document the burst rules the pitfalls section asks for, though it is still a draft.