Rate limiting caps how many requests a client can send within a time window to protect the server from overload, abuse, and attacks.
When the limit is exceeded, the server typically responds with `429 Too Many Requests` and tells the client when to retry via the `Retry-After` header.
Common algorithms include: (1) fixed window: reset a counter every window (e.g. a minute) — simple but allows bursts at window boundaries; (2) sliding window: smooths the boundary problem; (3) token bucket: refill tokens at a steady rate and spend one per request — allows some burst while capping the average rate, the most widely used; (4) leaky bucket: process at a fixed rate to flatten traffic. In distributed setups a shared store like Redis aggregates counts across servers.
In practice an API gateway handles this, applying different limits per user, API key, plan, or IP. It's good practice to expose remaining quota via headers like `X-RateLimit-Limit`, `Remaining`, and `Reset`. The goals are defending against DDoS, credential stuffing, and scraping abuse; fair resource allocation; and cost control. Clients should respect `429` and `Retry-After` and retry with exponential backoff — which also matters at points like webhook receivers where a sender's retries can surge.