Which functions get sacrificed first under strain should be decided ahead of time, not on the fly

What it is

Graceful degradation means a system, unable to sustain every function at once, deliberately gives up some secondary functions to keep the core function usable, rather than letting the whole system fail together. This entry is about when the degradation order should be decided: the full sequence — what gets dropped first, what next, what's protected until last — should be fixed at design time as an explicit tiered list, not worked out on the fly by whoever is on call at the moment a failure actually happens.

Why it happens

An in-the-moment judgment made during an incident is inherently made under three constraints at once — time pressure, incomplete information, and unknown consequences — and that's not the same quality of decision as one made calmly. Someone under pressure tends to rely on whatever information comes to mind most readily rather than systematically weighing the relative importance of each function, which means the same class of failure, handled by different people at different times, can end up sacrificing entirely different functions, making the user experience unpredictable. Fixing the degradation order in advance moves that judgment out of the high-pressure moment of an incident and into the design phase, where there's no time pressure and trade-offs can be weighed calmly; when the incident actually happens, the system just executes a list that's already been thought through, rather than making the call again from scratch.

Studying it

A common way to check whether a degradation order is truly "predefined" is to deliberately trigger a resource-shortage or partial-failure scenario in a test environment — a network outage, a server timeout, memory exhaustion — record the actual order in which functions get dropped, and compare it against the tiered order written in the design documentation. If the two match, the plan is genuinely doing its job; if the actual order shifts depending on who or when it was triggered, the "predefined" order exists only on paper and is still being decided at runtime. This kind of comparison also confirms a broader pattern: judgments made under time pressure differ systematically from ones made through deliberation, which is exactly why leaving the degradation order to be decided on the spot carries more risk.

Where it stops holding

A predefined degradation order assumes the possible failure modes can be enumerated in advance. For genuinely unexpected, rare compound failures, the plan may not cover the specific branch that actually occurs, and an in-the-moment judgment is still needed as a fallback — but this doesn't undermine the principle that whatever can be enumerated should be predefined; the smaller the gap the plan leaves uncovered, the smaller the risk exposure left to on-the-spot decisions.

Applying it

During system design, list every function that might need to be sacrificed under resource shortage or partial failure, and rank them into an explicit tier (core read functionality kept first, write functionality next, real-time sync and non-essential animation dropped first), and encode that list as executable configuration or logic, not just a paragraph in a document. Verification: regularly run failure drills in staging or test environments — deliberately induce resource shortage or service disruption — and check whether the actual order in which functionality is dropped exactly matches the predefined tiers. Any deviation means the tiered list isn't actually being enforced by the system, only written down on paper.

Related

• Same group: A10.08.1 fault tolerance — the system stays recoverable after an error occurs · A10.08.4 preserving completed work under partial failure · A10.08.6 a checklist for identifying irreversible actions
• Nearby: A10.07 the Swiss cheese model · A10.16 incident investigation and error reporting
• Search terms: graceful degradation · degradation tiers · time-pressured decision-making