Reliability & Resilience
Graceful Degradation & Load Shedding
When a system is overloaded, the choice isn't "healthy vs. down" — degrading gracefully (serving a cheaper, partial response) or shedding load (rejecting the least valuable requests first) keeps the system serving something instead of collapsing entirely under load it can't handle.
- Graceful degradation: turn off expensive, non-essential features (personalized recommendations, live counts) under load, while keeping the core function working
- Load shedding: reject requests outright once past a capacity threshold, deliberately choosing which to drop — lowest priority, non-authenticated, non-revenue-generating traffic first
- Shedding load early — before it consumes resources — protects the system's ability to serve the requests it does accept at full quality
- "Fail open" vs "fail closed" is a related decision for any protective mechanism: if the rate limiter itself fails, does traffic flow through unchecked (fail open, protects availability) or get blocked (fail closed, protects the backend)?
- This is a design decision made in advance, with explicit priority tiers, not an ad hoc reaction improvised during an incident
| Product | Full feature | Degraded under load |
|---|---|---|
| E-commerce checkout | Personalized "you may also like" | Static/cached recommendations, or hidden entirely |
| Social feed | Real-time like/comment counts | Cached, slightly-stale counts |
| Search | Full ranking with all signals | Simpler ranking, or cached top results |
| Video streaming | Highest available bitrate | Lower bitrate, same content |
boolean shouldShed(Request req, SystemLoad load) {
if (load.utilization() < 0.8) return false; // healthy — serve everyone
if (load.utilization() > 0.95) return req.priority() != Priority.CRITICAL; // shed all but critical
return req.priority() == Priority.LOW; // moderate overload — shed only low priority
}