Degradation Modes
Explicitly designed operating modes below "fully working" — declared, testable, and switchable rather than emergent.
Definition
Most systems have exactly two designed modes: working and broken. A system with declared degradation modes has several intermediate states, each with defined behaviour, defined triggers, and a way to enter and leave them deliberately.
A worked example
| Mode | Trigger | Behaviour |
|---|---|---|
| Normal | — | Everything |
| Reduced personalisation | Recommendation service degraded | Curated defaults; no per-user ranking |
| Read-only | Write path degraded | Browse and search work; no new orders |
| Essential only | Severe capacity loss | Core transaction only; all non-essential features disabled |
| Static | Total backend failure | Cached content and a status message |
The value is that each mode is designed and tested, so entering one is a decision rather than a discovery. Without declared modes, degradation is emergent: the system finds its own way to fail, and nobody knows in advance what will still work.
The prioritisation that makes it possible
Modes require knowing which traffic matters most, which means classifying it in advance:
- By user journey. Completing a purchase outranks browsing recommendations.
- By user state. A customer mid-transaction outranks a new arrival.
- By request type. A write that cannot be retried outranks a refreshable read.
- By client. A paying tenant may outrank a free one, if that is the agreed policy.
That classification must exist before the incident, propagated as a request attribute, because it cannot be invented under pressure.
Industry example
Real-time marketplaces need this acutely. An Uber-style dispatch system under severe load must continue matching riders and drivers even if surge calculation, ETA precision, personalised pricing and promotional logic are all degraded — because a marketplace that stops matching is a marketplace that is down, while one that matches with a slightly worse ETA is merely worse.
The design consequence is that the core matching loop must be able to run without any of the enrichment services, using simpler heuristics and staler data. That is not a fallback bolted on; it is a deliberate architectural separation of the essential loop from everything that improves it.
The same shape recurs: identify the single loop that is the product, and make sure it has no hard dependency on anything that merely makes it better.
Failure scenarios
- Modes that exist in documentation but have never been entered, so nobody knows if they work.
- No way to enter a mode without a deployment, which is far too slow during an incident.
- Entering a mode not visible externally, so support and customers do not know why behaviour changed.
- No exit criteria, so the system stays degraded long after the cause is fixed.
- Degraded mode more expensive, amplifying the incident.
Interview question
"Define three degradation modes for a product you know. What triggers each, what stops working, and how does the system get back?"