Rate limiter playground

One Poisson traffic stream feeds all four algorithms at once, configured to the same budget: L requests per window W. Change the load, fire a burst, and watch how differently each one copes. The bar shows how much each can still accept right now — green means headroom, red means it's about to throttle.

Incoming traffic 8 req/s

Limit 5 req / window

Window 1.0 s

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.

Algorithm	Burst behavior	Cost of the tradeoff
Fixed window	Cheap counter, resets on the boundary.	Allows up to 2× the limit across a boundary — the classic edge burst.
Sliding window	Weighted count over the trailing window — no edge burst.	More state and arithmetic per request than a fixed 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

Set incoming traffic below the sustained limit — everyone accepts ~100%. That's the easy regime.
Push incoming above the sustained limit and watch drops become unavoidable. No tuning saves you; the offered load is simply too high.
Hit Fire burst repeatedly: 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.