Token bucket, sliding window, Redis-based distributed limiting.

Rate Limiting — Protecting APIs from Overuse and Abuse

Rate limiting controls how many requests a client can make in a time window, protecting backend services from overload and abuse. Algorithms: fixed window (simple, burst risk), sliding window (accurate, costlier), token bucket (bursty but bounded), leaky bucket (smooth output). Distributed rate limiting with Redis ensures consistent enforcement across multiple API instances. Rate limit headers (X-RateLimit-*) help clients implement respectful retry behaviour.

Interactive Pipeline Flow

UnderstandImplementOptimise

🔑 Identify — by IP/user/key

Identify the rate limit subject: IP address (anonymous), user ID (authenticated), API key (service accounts). Different subjects may have different limits.

Architecture Diagrams

Distributed sliding window rate limiter with Redis sorted sets.

Loading diagram...

Key Design Decisions

📦Rate limiting must be distributed (Redis), not in-process

In-process rate limiting (server-local counter) allows 10x your limit with 10 API servers. A Redis-based distributed counter enforces limits globally across all instances.

⚙️Token bucket for APIs, leaky bucket for downstream protection

Token bucket is best for inbound API rate limiting — it allows short bursts. Leaky bucket is better for protecting downstream services — it smooths irregular traffic into a predictable stream.

📋Always return rate limit headers

X-RateLimit-Remaining and Retry-After help well-behaved clients pace themselves. Without these headers, clients either keep hammering with 429s or poll too conservatively. Good clients use them to optimize throughput.

Discussion