API Rate Limiting

Rate limiting controls how many requests a client can make to an API within a defined time window, protecting backend services from abuse, accidental overload, and ensuring fair resource allocation across consumers. Common algorithms include fixed window (simple but allows bursts at window boundaries), sliding window log (precise but memory-intensive), sliding window counter (good balance), token bucket (allows controlled bursts), and leaky bucket (smooths traffic to a constant rate).

Implementation typically happens at the API gateway or reverse proxy layer (e.g., Kong, NGINX, AWS API Gateway) using a distributed counter backed by Redis or a similar in-memory store. Rate limits are usually scoped per API key, per user, or per IP address, and different tiers may have different limits. The chosen algorithm affects burst behavior: token bucket allows short bursts up to a configured maximum, while leaky bucket enforces a steady request rate.

Rate limiting must be communicated clearly to consumers via standard response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) and a 429 Too Many Requests status code when limits are exceeded. The response should include a Retry-After header indicating when the client can retry. Well-designed rate limiting is transparent and predictable, allowing clients to implement backoff strategies without guessing.