Part 0 · 1 chapters · ~8 min

Rate Limiters

Fixed windows and their boundary bursts, sliding window logs and counters, token buckets and leaky buckets, distributed rate limiting with Redis, local versus global limits, limits per user, IP, API key and partner, and the response contract (429, Retry-After, RateLimit headers).

1

Four algorithms

code
// sliding window counter: estimate requests in the last 60 s from two fixed windows
function allowed(nowMs: number, limit: number, cur: number, prev: number): boolean {
  const elapsed = (nowMs % 60_000) / 60_000;              // fraction of the current window elapsed
  const estimate = cur + prev * (1 - elapsed);            // previous window weighted by its overlap
  return estimate < limit;
}
// token bucket: tokens = min(capacity, tokens + (now - last) * rate); allow if tokens ≥ 1
FOUR RATE LIMITERS
how each counts, and what each allows
fixed windowCount per minute bucket. Simple,one counter. Allows 2× bursts atwindow edges.sliding window logStore each request timestamp;count those in the last minute.Exact; memory per request.sliding window counterWeighted mix of current andprevious window counts. Close toexact; two counters.token bucketTokens refill at a rate up to acapacity; each request takes one.Bursts up to capacity.leaky bucketRequests drain at a fixed ratefrom a queue. Smooth output; addsqueueing delay.where they liveAPI gateways, Redis Lua scripts(BSD P2), Envoy, NGINX limit_req(leaky bucket).
swipe the figure sideways, or tap expand for full screen
1/6
fixed window
INCR a key per user per minute and EXPIRE it. Cheap, but a client can send the full limit at 12:00:59 and again at 12:01:00: twice the rate across the boundary.
simple; 2× bursts at edgesINCR + EXPIRE