MEDIUMInfrastructuresenior engineer
Design a Rate Limiter
Design a distributed rate limiting system to protect APIs from abuse and ensure fair usage.
Estimated Time: 30 minutes
#rate-limiting#api#redis#distributed-systems
Solution Overview
Use token bucket or sliding window algorithm with Redis for distributed state.
Hints to Get Started
1
Compare token bucket vs sliding window
2
How do you handle distributed state?
3
Consider race conditions
Requirements
functional
- •Limit requests per user/IP
- •Multiple rate limit rules
- •Graceful handling
- •Analytics
non functional
- •Low latency overhead
- •High accuracy
- •Distributed support
- •Configurable
Algorithms
token bucket
pros
- •Allows bursts
- •Smooth rate limiting
description
Tokens added at fixed rate, requests consume tokens
implementation
Track last_refill_time and token_count
sliding window log
cons
- •High memory usage
pros
- •Very accurate
description
Track timestamps of all requests in window
sliding window counter
pros
- •Memory efficient
- •Reasonably accurate
description
Combine fixed window counts with sliding calculation
Deep Dives
multiple limits
Hierarchical limits (per second, minute, hour)
response headers
X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After
graceful degradation
Queue requests vs hard reject
Distributed Implementation
storage
Redis for atomic operations
lua script
Atomic check-and-increment
race conditions
Use Redis transactions or Lua scripts