Problem
Unbounded request rates overwhelm services, enable abuse, and violate fair-use policies.
resilienceestablished · low operational burden
Rate Limiting
Also known as: throttling, rate-limiter
Intent
Control request rate to protect downstream services, enforce quotas, and prevent abuse.
Forces
- •Need to enforce per-client, per-endpoint, or global limits
- •Limits must be enforced with low latency overhead
- •Distributed systems need coordinated limiting across instances
- •Legitimate burst traffic should be allowed
Solution
✓ When to Use
- •Public APIs (prevent abuse, enforce tiers)
- •Internal services (protect downstream, fair sharing)
- •Login/auth endpoints (prevent brute force)
- •Expensive operations (search, report generation)
✗ When Not to Use
- •Internal high-throughput paths where latency budget is microseconds
- •When backpressure via queueing is more appropriate
- •Single-tenant systems with predictable load
Pros
- +Prevents overload and abuse
- +Enables tiered pricing / quotas
- +Observable: rejection metrics reveal capacity needs
Cons
- −Adds latency (distributed coordination)
- −False positives: legitimate bursts rejected
- −Complexity: distributed state, clock sync, key cardinality
Cost Profile
Infrastructure
Low (local) to Medium (Redis cluster)
Operational
Medium — tune limits, handle false positives
Cognitive
Low — well-understood concept
Failure Modes
Clock skew breaks fixed/sliding window
Redis outage → allow-all or deny-all (fail-open vs fail-closed)
Key explosion (per-user limits at high cardinality)
Burst rejection at window boundaries (fixed window)
Real-World Examples
Alternatives
- circuit-breaker
- bulkhead
- priority-queue
Related Patterns
- token-bucket
- sliding-window
- circuit-breaker
- api-gateway
Competency Domains
reliability opssecurity complianceeconomics evolution