Why it matters
A limit of "10 requests per second" means different things depending on the algorithm behind it. A fixed window resets on the second, so 10 requests at 0.9 s and 10 more at 1.0 s all get through: 20 in a tenth of a second. A token bucket allows bursts up to its size and then a steady rate. A sliding window log is exact but stores every timestamp; the sliding window counter approximates it with two numbers.
This simulator runs the same traffic through all five, request by request, and counts what each allows, rejects and, for the leaky bucket, how long requests wait in the queue. The "most in one window" column shows the busiest real second the server would see, which is the number that matters for capacity.
How to use it
- Set the limit and window.
- Choose a traffic pattern or paste request times.
- Compare allowed, rejected and the busiest window for each algorithm.
- Pick the algorithm whose behaviour matches what your backend can take.
FAQ
What's the difference between token bucket and leaky bucket?
A token bucket lets bursts through immediately up to its size. A leaky bucket queues them and releases them at a steady rate, so bursts are smoothed but delayed.
Why does a fixed window let twice the limit through?
Requests at the end of one window and the start of the next are counted separately, so up to twice the limit can arrive within one window length.
What is a sliding window counter?
It keeps counts for the current and previous windows and weights the previous one by how much of it still overlaps, which approximates a true sliding window cheaply.
Which algorithm should an API use?
A token bucket is the common choice: it allows short bursts and enforces an average rate. Use a sliding window when the per-window limit must be strict.
