Rate limiter

Rate limiters protect APIs from abuse and enforce fair usage quotas. Algorithms include token bucket (allows bursts), leaky bucket (smooth output), fixed window, and sliding window log or counter for accuracy. Distributed deployments use Redis with atomic INCR and TTL or centralized limiter service.

Return 429 with Retry-After header. Decide fail-open versus fail-closed when limiter store is down — payment APIs often fail closed; read APIs may fail open with logging.

On interviews: implement token bucket for 100 req/min per user, discuss Redis key design, and choose fail-open versus closed for your prompt.

Common pitfalls: race conditions without atomic operations; per-instance counters ineffective behind LB; clock skew breaking window boundaries.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Pick algorithm matching burst tolerance.
• Use centralized store for distributed limits.
• Return clear 429 and Retry-After.
• Define behavior when limiter unavailable.