Problem
Traffic spike exceeds capacity. All requests slow down or fail. Better to serve 80% well than 100% poorly.
resilienceestablished · medium operational burden
Load Shedding
Also known as: load-shed, priority-drop, graceful-degradation
Intent
Under overload, selectively drop low-priority requests to preserve capacity for high-priority work.
Forces
- •Capacity is finite, traffic is variable
- •Not all requests equal: payment > analytics > logging
- •Dropping must be fast (no queue drain latency)
- •Must not drop arbitrarily (fairness, SLA)
Solution
✓ When to Use
- •Traffic spikes exceed provisioned capacity
- •Multi-tenant: protect paying customers
- •Critical paths must stay available (payments, auth)
✗ When Not to Use
- •All requests equally critical
- •Capacity planning sufficient (rare spikes)
- •Dropping requests violates SLA (no degradation allowed)
Pros
- +Preserves critical throughput under overload
- +Graceful degradation vs total outage
- +Fast: decision at edge, no queue drain
Cons
- −Dropped requests = failed user actions
- −Priority classification: complex, subjective
- −Client handling: retry logic, UX for shed
- −Monitoring: shed rate, priority distribution
Cost Profile
Infrastructure
Low — logic in gateway/app
Operational
Medium — priority tuning, monitoring
Cognitive
Medium — priority design, fairness
Failure Modes
Priority misclassification: critical dropped, background served
Shed storm: aggressive shedding → more retries → more load
Client retry without backoff → amplification
No observability: shedding invisible until complaints
Real-World Examples
Alternatives
- rate-limiting
- circuit-breaker
- auto-scaling
- queue-based
Related Patterns
- rate-limiting
- circuit-breaker
- priority-queue
- auto-scaling
- backpressure
Competency Domains
reliability opsdistribution communicationeconomics evolutionsecurity compliance