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.
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.
Circuit Breaker
A circuit breaker stops calling a failing downstream service after a threshold of errors, preventing cascade failures. States: Closed (normal flow), Open (all calls fail-fast without attempting), Half-Open (limited test calls to check recovery). Prevents a slow/failing service from consuming all caller resources and propagating failure upstream.
Backpressure
Backpressure is a flow control mechanism where a slow consumer signals the producer to slow down, preventing buffer overflow and data loss. TCP's receive window is backpressure. In streaming systems (Kafka, reactive streams), backpressure propagates upstream – if the database is slow, the entire pipeline slows instead of dropping data.