Four Approaches to Limiting
Each algorithm trades off between complexity, precision, and computational overhead. Choose based on your traffic patterns and requirements.
All algorithms execute atomically in Redis using Lua scripts.
Token Bucket
Tokens accumulate at a constant rate. Requests consume tokens. When empty, requests are blocked.
Key Characteristics
Configuration
algorithm: TOKEN_BUCKET
capacity: 100
refillRate: 10 # tokens per secondLeaky Bucket
Incoming requests are queued. Processed at a constant rate. Smooths traffic spikes into steady flow.
Key Characteristics
Configuration
algorithm: LEAKY_BUCKET
capacity: 50
flowRate: 5 # requests per secondFixed Counter
Count requests in fixed time window. Reset happens at window boundaries.
Key Characteristics
Configuration
algorithm: FIXED_COUNTER
maxRequests: 1000
windowSize: 60 # secondsSliding Window
Continuously sliding window without resets. Most accurate. Every request checks entire window.
Key Characteristics
Configuration
algorithm: SLIDING_WINDOW
maxRequests: 100
windowTime: 60000 # millisecondsDetailed Comparison
Head to Head
| Metric | Token Bucket | Leaky Bucket | Fixed Counter | Sliding Window |
|---|---|---|---|---|
| Accuracy | High | High | Medium | Very High |
| Burst Handling | Controlled | Smoothed | Cliff Effect | Prevented |
| Memory Usage | Very Low | Low | Very Low | Medium |
| Redis Ops/Check | 3 | 3 | 3 | 4 |
| CPU Overhead | Low | Low | Very Low | Medium |
| Complexity | Medium | Medium | Low | High |
How to Choose
Decision Matrix
Do you allow burst traffic?
Use Token Bucket for flexibility. Use Sliding Window if precision is critical.
Must output be consistent?
Use Leaky Bucket. It guarantees constant processing rate.
Do you prioritize simplicity?
Use Fixed Counter. Fast, simple, good for internal APIs.
Is billing/SLA involved?
Use Sliding Window. The most accurate available algorithm.
Each algorithm is available in the playground. Test them with mock mode or connect to your own backend.