IoT devices sending data
Cloud / Knowledge library
Load Shedding
Rejects or degrades selected work when capacity is exhausted
Why learn Load Shedding?
It preserves core service health during extreme demand
The problem it solves
It prevents overload from collapsing every request path
Where it came from
Load Shedding is a distributed systems concept that rejects or degrades selected work when capacity is exhausted. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Load Shedding and distinguish it from a neighboring concept.
- Choose a realistic task where Load Shedding is appropriate.
- Identify a failure mode caused by misusing Load Shedding.
- Interpret a small design or result involving Load Shedding.
- Explain one tradeoff or limitation of Load Shedding.
Documentation and sources
- Designing Data-Intensive Applications (dataintensive.net)
Connect the ideas
Explore next
Real World Example
Resilient Analytics Ingestion for Global Logistics
A global logistics provider managing real-time telemetry from millions of shipping containers.
The business problem
During peak holiday shipping seasons, the telemetry ingestion service experiences massive request spikes that saturate CPU and memory, causing cascading failures and total system downtime for all clients.
How this topic solves it
Load shedding protects the core ingestion service by proactively rejecting non-critical background telemetry updates when system capacity thresholds are breached, ensuring that high-priority delivery status updates continue to be processed without interruption.
- Define a priority hierarchy for incoming telemetry packets based on business impact.
- Implement a monitoring layer to track current system resource utilization against defined safety thresholds.
- Configure a request interceptor that checks the current load before processing any incoming payload.
- Drop low-priority packets immediately at the edge when the system enters a high-load state.
- Return a specific status code to the client to signal that the request was rejected due to capacity constraints.
This diagram illustrates how incoming requests are filtered based on system capacity before reaching the processing engine.
Tracks CPU/Memory usage
Decides to accept or reject
Handles high-priority data
Drops low-priority packets
- Telemetry Source → Sends request → Interceptor
- Load Monitor → Provides capacity status → Interceptor
- Interceptor → Passes high-priority → Core Processor
- Interceptor → Rejects low-priority → Discard Queue
Expected business outcome
The ingestion service maintains stable performance for critical operations during traffic surges, preventing total system collapse at the cost of temporary data loss for non-essential telemetry.
Limitations and checks
Load shedding introduces partial data loss for lower-priority tasks, which can lead to incomplete historical datasets; operators must monitor rejection rates to determine if capacity expansion is required.