What it is
Summary: Load shedding is an overload-control mechanism that intentionally rejects, drops, defers, or downgrades work once capacity thresholds are crossed.
The objective is to preserve protected paths and keep the system in a controllable operating envelope instead of entering queue explosion and timeout collapse.
Why it matters
Summary: Under severe pressure, accepting every request shifts failure to deeper, more expensive layers.
If you accept work you cannot complete, you saturate queues, worker pools, and dependencies simultaneously. Intentional shedding keeps overload local and recoverable.
What problem it solves
Summary: Load shedding prevents system-wide collapse by sacrificing less important work first.
- Protects critical SLAs from noisy best-effort traffic.
- Limits tail-latency spirals from unbounded queued work.
- Reduces cascading dependency failures caused by overload fan-out.
- Creates deterministic behavior during incident conditions.
How it works
Summary: Effective shedding depends on priority classes, thresholds, and decision points across the request path.
Priority classes
- Critical: contractual or correctness-sensitive operations.
- Important: user-visible but degradable operations.
- Best-effort: background, enrichment, or optional work.
Decision boundaries
- Ingress: reject early when global saturation crosses thresholds.
- Queue admission: block enqueue for lower classes as depth grows.
- Worker dispatch: skip low-priority tasks when drain lag exceeds budget.
- Downstream boundary: avoid sending optional calls to unhealthy dependencies.
Load shedding vs admission control
Summary: Admission control is usually the earlier intake boundary; load shedding is runtime triage once pressure is already high.
Admission control rejects or defers work before it enters deep processing paths. Load shedding protects the system when overload still exceeds safe operating budgets.
Load shedding vs rate limiting
Summary: Rate limiting enforces planned quotas; load shedding is runtime overload triage.
Rate limiting is usually policy and fairness control. Load shedding activates when current capacity cannot sustain accepted demand.
What work should be shed first
Summary: Shed optional, retryable, and latency-tolerant work before correctness-critical paths.
- Analytics fan-out, expensive enrichments, and asynchronous notifications without strict deadlines.
- Non-critical reads that can serve stale data instead.
- Low-priority tenant operations during emergency protection windows.
What it is not
Summary: Load shedding is not random packet loss, and not an excuse for permanent underprovisioning.
It must be intentional, priority-aware, and observable, with explicit customer and operator semantics.
Tradeoffs and constraints
Summary: Bad shedding policy can create unfairness, confusing UX, or oscillating system behavior.
- Aggressive thresholds can reject too early and waste capacity.
- Slow thresholds can still allow queue collapse before shedding starts.
- Inconsistent semantics (drop vs reject vs defer) complicate client handling.
- Priority abuse by clients can undermine fairness without strong admission policy.
Where it fits in the system
Summary: Load shedding is part of the overload stack with admission control, backpressure, and graceful degradation.
Admission and rate limits shape traffic, backpressure constrains queued work, shedding discards overflow intentionally, and graceful degradation preserves essential product behavior for accepted requests.
Production scenarios
Summary: Shedding strategy should reflect operational priorities in multitenant systems and migration events.
- Multitenant workflow platform: reject low-priority report generation while preserving command execution and state transitions.
- Customer notification service: defer promotional campaigns while preserving password reset and compliance notifications.
- Regional migration incident: shed non-essential replication jobs to stabilize primary control and health telemetry.
Design guidance
Summary: Make shedding observable and contract-aware so clients and operators can respond correctly.
- Define clear response semantics: reject (4xx/5xx), defer, drop with audit trail, or downgrade.
- Instrument shed rate by priority class and entry boundary.
- Track protected-path success rate during overload windows.
- Rehearse threshold tuning with load tests and incident game days.
Closing summary
Summary: Load shedding is intentional overload triage that protects system health and critical user paths when capacity is exceeded.