FixedWindowCounter

Simplest possible implementation: count requests in a fixed time bucket (e.g. per-minute), reset the counter at the boundary — cheap, but allows a burst of up to 2x the limit right at the window boundary.

Why we need this / what value this brings

The cheapest possible rate limiter to implement and reason about — a single counter and a reset timestamp per client.

When to use this

A reasonable first implementation for most endpoints, upgraded to sliding window only if the boundary-burst flaw is actually exploited or matters.

How to use or implement this

Store a counter and window-start timestamp per client key (e.g. in Redis with a TTL), increment on each request, reject once the counter exceeds the limit within the current window.

Research questions

• Fine as a first implementation given its simplicity — worth knowing its boundary-burst flaw before relying on it for anything abuse-critical.

---

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