Mental model
Rate limiting regulates the frequency of client API requests to protect server infrastructure, prevent Denial-of-Service (DoS) overloads, and enforce API monetization tiers.
Incoming Client HTTP Request
Extract Client IP / API Key
Execute Redis Sliding-Window Script
Evaluate Request Count vs Limit
Return 200 OK or 429 Too Many Requests
Theory
- Token Bucket: Refills tokens at a constant rate; permits burst traffic up to bucket capacity.
- Leaky Bucket: Queues requests and processes them at a strict constant output rate; smooths out bursts.
- Fixed Window Counter: Counts requests per fixed minute/hour window; vulnerable to double-limit traffic spikes at window boundaries.
- Sliding Window Log / Counter: Measures requests over a moving time window; highly accurate.
python(21 lines)
1# Redis Sliding-Window Rate Limiter in Python
2import time
3import redis.asyncio as aioredis
4
5redis = aioredis.from_url("redis://localhost:6379")
6
7async def is_rate_limited(user_id: str, limit: int = 100, window_seconds: int = 60) -> bool:
8 now = time.time()
9 clear_before = now - window_seconds
10 key = f"rate:{user_id}"
11
12 async with redis.pipeline(transaction=True) as pipe:
13 pipe.zremrangebyscore(key, 0, clear_before)
14 pipe.zadd(key, {str(now): now})
15 pipe.zcard(key)
16 pipe.expire(key, window_seconds)
17 results = await pipe.execute()
18
19 request_count = results[2]
20 return request_count > limit
Alternatives and trade-offs
- Fixed Window: Minimal memory footprint; allows 2x limit spikes near window resets.
- Sliding Window Log (Redis ZSET): 100% boundary accuracy; higher Redis RAM usage for high request volumes.
- Token Bucket: Supports legitimate burst traffic while maintaining average rate limits.
Failure modes and misconceptions
- Non-Atomic Rate Limit Checks: Executing
GET countfollowed bySET countin separate non-atomic commands causes race conditions under high concurrency. Always use Redis Lua scripts or MULTI/EXEC pipelines. - Missing Retry-After Headers: Returning HTTP
429 Too Many Requestswithout an explicitRetry-Afterheader causes aggressive client retries.
Reflect before revealing the guide
Decision scenario
Use Redis Sliding Window rate limiting for API Gateway authentication tiers to enforce accurate client rate limits without window boundary traffic spikes.
Learning outcomes
- Implement Token Bucket, Leaky Bucket, and Sliding Window rate limiting algorithms.
- Execute atomic rate limit calculations using Redis pipelines and Lua scripts.
- Attach standard HTTP rate limit headers (
X-RateLimit-Limit,X-RateLimit-Remaining,Retry-After).
Trade-offs
Rate limiting guarantees API availability and protection against abuse, but requires fast in-memory stores like Redis for distributed state tracking.