Systems Lab
lab / rate-limiter

Rate limiter playground

One traffic stream feeds all four algorithms at once, on the same budget: L requests per window W. Slow the playback right down to watch a single request land, or crank the load up to see steady-state stress. The scoreboard up top compares all four at a glance — click one to jump to it.

Speed

What you're looking at

All four limiters are given the identical budget — L requests per W seconds, so a sustained limit of L / W per second. The single most important relationship is the one in the banner: when offered load exceeds the sustained limit, no algorithm can accept everything. They only differ in how they cope — drop the excess, buffer it, or let it slip through at the seams.

AlgorithmBurst behaviorCost of the tradeoff
Fixed window Cheap counter, resets on the boundary. Allows up to the limit across a boundary — the classic edge burst.
Sliding window Exact count over a trailing window — no edge burst. Stores a timestamp per accepted request — more memory than a single counter.
Token bucket Passes bursts instantly, up to the bucket capacity. Downstream sees spiky output; a full-size burst hits at once.
Leaky bucket Buffers the burst and releases at a constant rate. Adds latency — requests wait in the queue. Drops when the queue fills.
Try this
  • Leave it at 0.25× speed and watch one request at a time land in each algorithm — the calmest way to see the mechanism.
  • Push incoming traffic above the sustained limit and watch drops become unavoidable. No tuning saves you; the offered load is simply too high.
  • Hit Fire burst: token bucket lets the whole spike through, leaky bucket's latency climbs as it buffers, the windows drop whatever's over quota.
  • Set the window to 4s and watch fixed window let a double-burst through right after its reset — then compare the sliding window, which doesn't.