Rate Limiting & Throttling
Master rate limiting algorithms — Token Bucket, Leaky Bucket, Fixed Window, Sliding Window Log, and Sliding Window Counter — with Redis-based distributed implementations and real-world API protection patterns.
Master rate limiting algorithms — Token Bucket, Leaky Bucket, Fixed Window, Sliding Window Log, and Sliding Window Counter — with Redis-based distributed implementations and real-world API protection patterns. This hands-on tutorial focuses on practical implementation of rate limiting & throttling concepts.
Rate Limiting & Throttling
Rate limiting controls the rate of requests a user, IP, or API key can make in a given time window. Without it, a single misbehaving client can consume all your resources, causing degraded service for everyone else.
[!IMPORTANT] Rate limiting is not just about preventing abuse — it also protects your downstream services from being overwhelmed during traffic spikes, even from legitimate users. Design rate limits for normal usage × safety factor, not just worst-case abuse scenarios.
Why Rate Limiting?
- DDoS Protection — Limit request rate per IP to absorb attack traffic
- API Abuse Prevention — Stop scrapers, bots, credential stuffing
- Fair Usage — Ensure one heavy user doesn't starve others
- Cost Control — Prevent runaway usage from bugs (infinite retry loops)
- Downstream Protection — Limit traffic to slow/expensive services (ML inference, external APIs)
Rate Limiting Algorithms
Distributed Rate Limiting with Redis
In production with multiple API servers, each server needs a shared counter — otherwise rate limits are per-server, not per-user:
Rate Limiting Strategies by Layer
| Layer | Tool | What It Protects |
|---|---|---|
| DNS / CDN | Cloudflare Rate Limiting | DDoS, volumetric attacks |
| Load Balancer | nginx limit_req | Per-IP request flooding |
| API Gateway | AWS API Gateway, Kong | Per API key, per endpoint |
| Application | Redis-based counter | Per-user business logic limits |
| Database | Connection pool limits | DB overload prevention |
Quiz
Quiz
Question 1 of 2The Token Bucket algorithm allows bursts. If a bucket has capacity=10 and rate=1 token/second, a user who hasn't made requests in 10 seconds can send how many requests instantly?
Key Takeaways
✅ Token Bucket allows bursts up to capacity — best for APIs with occasional heavy users (GitHub API).
✅ Leaky Bucket enforces smooth output rate — best for payment processors and email senders.
✅ Sliding Window Log is most accurate but memory-intensive; Sliding Window Counter approximates it cheaply.
✅ Distributed rate limiting requires Redis — in-memory counters are per-server and ineffective.
✅ Always return X-RateLimit-* headers so clients can implement proper backoff.
✅ Return 429 Too Many Requests with a Retry-After header when blocking.
Official Resources
- 📖 Cloudflare Rate Limiting — Edge-level rate limiting
- 📖 Redis Rate Limiting Patterns — Official Redis guide
- 📖 NGINX Rate Limiting —
limit_req_zoneconfiguration - 📖 Stripe Rate Limits — Real-world API rate limit design
What's Next?
Rate limiting protects you from overload — but what about handling failures in your downstream dependencies?
Next: Circuit Breaker, Retries & Backoff — How to gracefully handle downstream failures without cascading them to your users.