Skip to main content
networking

Rate Limiting

Rate limiting restricts the number of requests a client can make in a time window. Prevents abuse (brute force, scraping), protects backend resources, and ensures fair usage. Algorithms: fixed window, sliding window, token bucket, leaky bucket. Return HTTP 429 Too Many Requests with Retry-After header when limits are exceeded.

Definition

Rate limiting enforces a maximum request rate per client (by IP, API key, user ID, or other identifier). Common algorithms: token bucket (tokens regenerate at a fixed rate; each request consumes one; burst allowed up to bucket size), sliding window log (track timestamps of recent requests; reject when window count exceeds limit), and fixed window counter (simple counter reset every interval – has burst-at-boundary issues). Rate limits should be communicated via response headers: X-RateLimit-Limit (max requests), X-RateLimit-Remaining (requests left), X-RateLimit-Reset (window reset time). When exceeded, return HTTP 429 with Retry-After header. Implementation options: application-level (Redis-backed counters), reverse proxy (Nginx limit_req), API gateway (Kong, AWS API Gateway), or CDN edge (Cloudflare Rate Limiting). Distributed rate limiting across multiple server instances requires shared state (Redis, DynamoDB) or synchronized local counters.

Examples

  • Nginx: limit_req_zone $binary_remote_addr zone=api:10m rate=100r/m; limit_req zone=api burst=20;
  • Redis: INCR key; EXPIRE key 60 (simple fixed-window counter)
  • Response: X-RateLimit-Limit: 100, X-RateLimit-Remaining: 0, Retry-After: 45

Related Protocols

Related Terms