Rate Limiter Playground
Token bucket, leaky bucket, fixed window, and sliding window — same traffic, four decisions.
Generated
0
Accepted
0
Rejected
0
Last
—
Idle time stores tokens, so the first burst is graceful; sustained excess is rejected.
Decision stream (recent)
How this simulator works
One clock, one event stream, and traffic patterns you can provoke. Watch how each algorithm decides to accept, queue, or reject the same request stream.
Token bucket
Tokens refill at a fixed rate up to a capacity. A request is accepted only when it can spend one token, so quiet periods build burst headroom. Great default for public APIs.
Leaky bucket
Requests enter a finite queue and drain at a steady rate. Smooths output to the backend at the cost of latency when the queue fills.
Fixed window
Counts requests per discrete window and resets abruptly. Cheap, but a client can send at both ends of a boundary for a double burst.
Sliding window log
Keeps accepted timestamps and expires them individually over a rolling interval. Fairer and more precise, but uses more memory.