Three algorithms. One traffic spike. Each one rejects differently.
What problem are we solving?
A single client with a buggy retry loop can take down an entire API. A rate limiter sits in front of a service and decides, per request, whether to let it through. The hard part isn't the counting — it's choosing an algorithm that matches your traffic shape: token-bucket allows short bursts but enforces a long-run rate, leaky-bucket smooths everything into a steady stream, and fixed-window is dead-simple but spike-prone at window boundaries.
Live simulation
updates every 1s
In30/s
Limitertoken-bucket
0
Bucket capacity30
Refill rate20/s
Steady state≤ 20/s allowed
Each request consumes 1 token. Bucket refills at the limit rate, capped at capacity.
Allowed
0/s
Rejected
0/s
Green dots = allowed, red dots = rejected. Internal state visualization updates each tick.
Controls
30 req/s
20 req/s
10
Extra capacity above the steady rate
Live metrics
Allowed (total)00 this tick
Rejected (total)00 this tick
Rejection rate0%
Current allowed rate0 req/s
Algorithm state
Tokens0 / 30
What just happened?
30/s exceeds the steady-state limit of 20/s. The token bucket is draining its burst reserve — currently at 0 of 30 tokens. Once empty, only 20/s are allowed; the rest are rejected. Burst absorbs short spikes; steady state enforces the limit.
Try this
Push past the limit
Set request rate higher than the limit and watch each algorithm reject differently. Token-bucket absorbs the burst first; fixed-window rejects immediately once the cap is hit.
If your API can handle 50 req/s and you cap at 20, why does the user experience differ between token-bucket (smooth) and fixed-window (bursty at window edges)?
Key takeaway
Rate limiting is the server's seat belt: it doesn't make you faster, it stops you from dying. Algorithm choice is a tradeoff between simplicity and fairness — token-bucket is the safe default because it tolerates short bursts while still enforcing a long-run cap. Fixed-window is easiest to implement but worst under bursty traffic. Leaky-bucket produces the smoothest downstream load but adds queueing delay.
