Rate Limiter

01What does a rejected request actually see?

HTTP 429 with Retry-After and X-RateLimit-Limit/Remaining headers — a well-behaved client can back off instead of hammering.

02Limited by what — user, API key, IP, endpoint?

All of them, per policy: each key type carries its own quota and window, and one request can be checked against several (user AND endpoint).

03Who owns the limiter — every service, or one layer?

One shared layer (gateway middleware or sidecar): services declare policies; the counting machinery exists exactly once.

04Do clients get warning before they hit the wall?

Yes: every response carries remaining-quota headers, so a well-built client self-throttles long before the first 429.

05A request matches several policies - which one answers?

All are checked and the most restrictive wins; the 429 names which limit tripped, because a debuggable rejection is part of the contract.

06Free tier and paid tier share this system?

Yes: policies key on tier attributes, and a tier upgrade changes the effective quota at the very next request - no cache to wait out.

01How much latency can the check add?

About a millisecond: one atomic in-memory operation (local or one Redis round trip) — the limiter must never be the slow part.

02Two requests race for the last slot — what happens?

Exactly one passes: check-and-decrement is a single atomic operation (Redis Lua or equivalent), never read-then-write.

03The limiter goes down — do we block everything?

Fail-open with an alert: dropping rate protection briefly beats turning the limiter into a single point of failure.

04Same client, different gateway node — same answer?

Yes: counters live in a shared store keyed by client, not per node — otherwise N nodes silently mean N× quota.

05What about the window-edge burst?

Fixed windows allow 2× quota straddling the boundary; a sliding-window counter weights the previous window to smooth it at almost no memory cost.