Graceful Degradation
Also known as: degraded mode, fallback behaviour
Graceful degradation is the property of continuing to deliver core functionality with reduced features when a dependency fails, instead of returning an error. It requires deciding in advance which parts of a response are essential and what each optional part falls back to.
Last reviewed · Part of the Architecture Glossary
In practice
Classify every dependency on a page as critical or optional, and write the fallback for each optional one:
| Dependency | Class | Fallback when it fails |
|---|---|---|
| Product catalogue | Critical | Fail the request — there is no page without it |
| Recommendations | Optional | Hide the shelf |
| Personalised pricing | Optional | Show list price with a notice |
| Review count | Optional | Serve the last cached value, stale |
| Inventory check | Critical-ish | Allow the order, verify asynchronously |
Two implementation notes. Optional dependencies need shorter timeouts than critical ones — a recommendation call must not hold a request for 3 seconds. And the degraded path must be exercised: a fallback that has never run in production is a hypothesis, which is why chaos experiments and a degraded-mode feature flag belong in the design.
When it matters
Any composite page, any request that aggregates several services, any mobile client on an unreliable network.
Common mistake
Treating every dependency as critical because nobody wants to decide. The result is a page whose availability is the product of eight services' availabilities — see availability nines — when six of them were never needed to render something useful.
See also
- Circuit BreakerA circuit breaker wraps calls to a dependency and stops making them once the failure rate crosses a threshold, failing fast for a cool-down period before letting a trial request through.
- BackpressureBackpressure is the mechanism by which an overloaded component signals upstream to slow down, rather than accepting work it cannot complete.
- Blast RadiusBlast radius is the extent of damage a single failure or change can cause — how many users, tenants, regions or services are affected when one component fails.