Load Shedding
Incoming work can exceed sustainable processing capacity.
- Overload signalOverload signal: Utilization signals scarce capacity.
- SelectionSelection: Work is admitted or dropped by priority.
- ProtectionProtection: Remaining capacity stays available for core work.
Context
Why this is important
Preserve core capacity during overload.
Preserve core capacity during overload.
Load Shedding: inspect the decision
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. Under heavy shop load, the search platform approaches its tested limit. The entry point rejects extra preview queries with a clear overload response, while order confirmation and payment status retain priority. The API ends waiting optional requests early instead of holding them in an unbounded queue. Dashboards measure rejection rate, latency, and successful core orders. As the queue drains, the system resumes accepting previews.
This is how you read the picture
- Overload signal Overload signal
- Selection Selection
- Protection Protection
| Concept | Meaning | Review question |
|---|---|---|
| Overload signal | Utilization signals scarce capacity. | Which work is rejected first under overload? |
| Selection | Work is admitted or dropped by priority. | Where should the overload threshold be determined? |
| Protection | Remaining capacity stays available for core work. | What consequence must the team check for shed work? |
Benefits & limitations
Helps if:
- Preserve core capacity during overload.
- Check overload thresholds and priorities at the ingress boundary.
Boundaries
- Incorrect priorities can shed valuable work.
- Shedding at the wrong ingress point can lose paid work or amplify retries.
In practice
- Derive the rejection threshold from the tested search-platform capacity and define which preview requests are shed first as the queue grows.
- Generate load above the threshold and check that rejection happens early at ingress while order confirmation and payment status still receive responses.
- Measure queue length, rejection rate, core orders, and recovery together; verify previews return only after sustained relief.
Read the detailed explanation
Load shedding drops or rejects work when a system reaches sustainable capacity. It protects remaining resources by filtering lower-priority requests early.
The selection rule should consider business priority, work already in flight, and retry behavior. Rejection should be visible and, where possible, actionable; otherwise clients may add fresh load through immediate retries.
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. Under heavy shop load, the search platform approaches its tested limit. The entry point rejects extra preview queries with a clear overload response, while order confirmation and payment status retain priority. The API ends waiting optional requests early instead of holding them in an unbounded queue. Dashboards measure rejection rate, latency, and successful core orders. As the queue drains, the system resumes accepting previews. rate limit load shedding and rate limiting help compare this decision with adjacent concerns.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which work is rejected first under overload?
View the solution with justification
Preview queries; order confirmations keep higher priority.
ApplyingTransferred to a new situation
Where should the overload threshold be determined?
View the solution with justification
At the bottleneck or ingress point before queues continue to grow.
EvaluateWeighing an alternative
What consequence must the team check for shed work?
View the solution with justification
Retries, user messaging, and possible loss of already accepted work.
Explore further
These building blocks continue the thoughts of this page.