Graceful Degradation
When parts fail, keep the core experience working instead of failing completely.
To an executive
When a part fails, customers should still be able to do the most important thing. A reduced service keeps revenue and trust that a complete outage would lose.
To an engineer
Decide which features are core, then make other dependencies soft. When one fails, serve stale, default or partial results instead of an error.
The idea
Aircraft are designed to keep flying with an engine out. Systems should be designed to keep serving their most important function even when dependencies fail.
That requires knowing what "core" means. Not all features are equal: checkout matters more than recommendations, and showing an order's status matters more than showing a personalised banner. The AWS Well-Architected Framework frames this as turning hard dependencies into soft ones, so a component can still do its central job with stale data, alternative data or no data from a failing dependency.
Why it works
Most failures are partial. It is rare for everything to break at once. Usually one dependency is slow or down while the rest are fine, and a page that fails completely because of one missing panel wastes everything that still works.
Users forgive missing extras, not broken essentials. A shopper barely notices missing recommendations but abandons a basket that will not load. Protecting the core keeps the business running during an incident.
Shedding load protects the core. Turning off expensive, non-essential features under pressure frees capacity for the work that matters, which can stop a slowdown becoming an outage.
Where it applies
- Composite pages and APIs that gather data from several services.
- Systems with optional enrichment, such as recommendations, analytics, personalisation and search suggestions.
- Configuration and parameter stores, where cached values or safe defaults can stand in during an outage.
- Peak events, where planned load shedding keeps the most valuable flows alive.
How to apply
- Rank features by criticality with the business, not just engineering. Agree what must always work.
- Map each dependency's failure modes: down, slow, returning errors, returning nonsense.
- Design a degraded response for each: a timeout, a cached result, a static default, a partial response or a hidden component.
- Add switches that let operators turn off non-essential features quickly under load.
- Test the degraded paths regularly. A fallback that has never run is a guess, and simple fallbacks are safer than clever ones.
Example scenario
When the recommendation service went down, product pages returned errors, because the page waited for every panel before rendering. A minor feature took out the most important page on the site.
The team gave each panel a short timeout and a fallback: the page showed bestsellers from a static cache when recommendations were unavailable. During the next recommendation outage, product pages kept loading and customers kept buying; only the dashboards showed anything had happened.
Questions to ask
- What is the one function that must keep working when everything else is failing?
- What does this page or API return when that dependency is down?
- Which features can we switch off under load, and who decides?
When not to use it
- When correctness is the core function. A payment or ledger update that cannot complete safely should fail clearly, not degrade into a partial write.
- When a fallback is more complex than the primary path. Rarely exercised, complicated fallbacks can cause worse outages than the failure they handle.
How it misleads you
Degrading silently in ways that corrupt data or mislead users. Degradation should be visible to operators and honest to users. Watch too for degraded modes that become permanent: a fallback that quietly runs for months hides a dependency that nobody is fixing.
In the wild
Further reading
Last reviewed · Suggest an improvement