Rate limiting

Rate limiting protects services by capping requests per user, IP, API key, or tenant—using token bucket, leaky bucket, fixed window, or sliding window algorithms. Distributed limits need shared counters (Redis) with careful clock sync.

| Strategy | Behavior | |----------|----------| | Token bucket | Allows bursts up to bucket size | | Sliding window | Smoother than fixed window per minute | | Per-tenant | Fairness in multi-tenant SaaS | | Global | Protect shared dependencies |

Return **429** with `Retry-After` and stable error bodies. Rate limits belong at edge (API gateway, CDN) and on expensive internal endpoints.

On interviews: token bucket vs sliding window; distributed rate limit race conditions; difference from throttling queues; UX for limited clients.

Common pitfalls: limits only at edge while internal services uncapped; per-IP limits punishing NAT users; no observability on who gets throttled.

The trade-off is protecting stability versus blocking legitimate burst traffic.

Checklist:

• Limit at edge and hot internal paths.
• Use shared store for multi-instance limits.
• Emit metrics on rejections.
• Document limits in API contracts.