Problem
Choosing wrong algorithm: burst rejection, memory explosion, boundary spikes. Each has distinct behavior under load.
resilienceestablished · low operational burden
Rate Limiting Algorithms
Also known as: token-bucket, leaky-bucket, sliding-window, fixed-window
Intent
Compare rate limiting algorithms: token bucket, leaky bucket, fixed window, sliding window — trade-offs and use cases.
Forces
- •Burst handling vs smooth rate
- •Memory efficiency at scale
- •Boundary behavior (window edges)
- •Distributed coordination cost
Solution
✓ When to Use
- •Any rate limiting implementation
- •Choosing algorithm for new limiter
- •Debugging rate limiter behavior
✗ When Not to Use
- •No rate limiting needed
- •Team not implementing limiter
Pros
- +Right algorithm = predictable behavior
- +Token bucket: burst + steady state
- +Sliding window counter: best practical trade-off
Cons
- −Algorithm choice affects user experience
- −Distributed adds latency, consistency concerns
- −Token bucket: burst can overwhelm downstream
Cost Profile
Infrastructure
Low (in-memory) to Medium (Redis)
Operational
Low — algorithm choice
Cognitive
Medium — algorithm properties
Failure Modes
Fixed window: 2x burst at boundary
Token bucket: burst overwhelms downstream
Sliding log: memory explosion at high rate
Redis latency: rate limit check adds ms
Clock skew: window boundaries wrong
Real-World Examples
Alternatives
- circuit-breaker
- bulkhead
- load-shedding
- backpressure
Related Patterns
- rate-limiting
- token-bucket
- sliding-window
- leaky-bucket
- circuit-breaker
Competency Domains
resilience opsdistribution communicationeconomics evolutiondata state