Rate Limiter Scope — five algorithms, one traffic stream

Peak is the honest number

Peak is the most requests a limiter actually delivered in any rolling minute — not just the clock-aligned ones it happens to be counting. A correct limiter's peak never exceeds its limit.

Hit Boundary attack: a full quota just before a window edge and another just after. Both minutes are individually legal, so the fixed window waves all of it through — and the rolling minute straddling the boundary sees twice the limit. Its counter never notices.

Two things that look like bugs

The leaking bucket is scored on when requests leave its queue, not when they arrive — it defers work instead of refusing it, so what the server downstream sees is the drip, not the burst. Its cost is latency, and it is charged to the requests it accepts.

The token bucket's peak legitimately runs over the limit. A bucket sized to the limit starts full, so it can spend its whole capacity plus whatever refills meanwhile. That is the burst allowance you asked for when you chose it.

Try this

Set the client rate below the limit and switch from Metronome to Poisson. Same average rate — but real arrivals clump, and the clumps breach a limit the average never approaches. Rejections appear from nothing.

That is why a customer can be genuinely under quota and genuinely getting 429s, and not be lying about either.