Rate Limiter Playground

Rate limiter · 5 requests / 4s0 sent

Click fast, then pause and click again — watch the three diverge.

Fixed window

One counter per interval. Cheap, and lets a double burst through at the boundary.

0.0 / 5 used0 blocked

Sliding window

Weights the previous window by how much of it is still in view. No boundary burst.

0.0 / 5 used0 blocked

Token bucket

Refills steadily up to a cap. Permits a deliberate burst, bounds the sustained rate.

0.0 / 5 used0 blocked

01 — WhyWhat made this worth building

I have watched three separate teams ship a fixed-window limiter and then get surprised by a burst at the window boundary. It is much easier to explain by letting someone produce the burst themselves than by drawing it on a whiteboard.

02 — NotesHow it works

A fixed window counts requests per calendar interval — 100 per minute, reset on the minute. It is one counter and one expiry, which is why everyone reaches for it first. The flaw is the boundary: 100 requests at 11:59:59 and 100 more at 12:00:00 is 200 requests in one second, and every one of them is inside the limit.

A sliding window fixes that by weighting the previous window by how much of it is still in view. It costs two counters instead of one and is an approximation, but the burst at the boundary disappears.

sliding window approximation

const elapsed = (now % windowMs) / windowMs;      // 0..1 through current window
const estimate = prevCount * (1 - elapsed) + currCount;

if (estimate >= limit) reject();
else currCount++;

A token bucket is the one you usually want for a public API. Tokens refill at a steady rate up to a cap; each request spends one. It permits a deliberate burst up to the bucket size while still bounding the sustained rate — which matches how real clients behave, since they idle and then do ten things at once.

All experiments