SlidingWindow

Counts requests in a moving time window (log-based: exact but memory-heavy; counter-based: approximate but cheap) — avoids the fixed-window bug where a burst straddling two windows doubles the effective limit.

Why we need this / what value this brings

Avoids the fixed-window bug where a client can send 2x the intended limit by timing requests to straddle a window boundary.

When to use this

When rate-limit accuracy matters more than raw simplicity — e.g. protecting a costly endpoint where the fixed-window boundary exploit is a real concern.

How to use or implement this

Use a sliding window counter (approximate, cheap — weights the previous window's count) as a good middle ground before reaching for a full sliding log (exact, more memory).

Research questions

• Sliding window log vs sliding window counter — what's the actual memory/accuracy trade-off at Localz's expected request volume?

---

Empty folder — drop notes, links, and findings here as you research.