Graceful degradation
Resilience & Reliability
Start lesson · ~15 minMembers
Graceful degradation keeps a service doing its core job when some of its dependencies fail, by giving up the parts that aren't essential. Each dependency is critical or optional. When an optional one fails — recommendations, reviews, a thumbnail — the page is shown without it, or with cached, stale or default data, instead of an error page. Under heavy load, a kill switch can turn optional features off to save capacity. Each failure needs a decided answer, fail open or fail closed, and the degraded path must be simple and exercised often, because a fallback that only runs during an outage is the one most likely to fail — or to move the load onto something else and bring it down.
- Use when
- Pages that combine a core function with optional parts — recommendations, reviews, personalization · Dependencies whose data can safely be served stale or from a default for a while · Planned high-load events, where optional features can be switched off in advance
- Avoid when
- Where correctness can't be relaxed — charging a card, moving money (fail closed instead) · As an untested switch that only runs during an outage — make the primary path stronger instead
- Trade-offs
- Higher availability of the core job, for a worse experience while degraded and code paths that must be tested · Stale or default data keeps pages up, but may show wrong values for a while · Kill switches save capacity under load, but someone has to decide what goes first — and keep the switches working
3 objectives · 9 misconceptions
- Explain how sorting dependencies into critical and optional lets a page keep its core job when an optional dependency fails, and why waiting on an optional call can still take the page down.
- Predict what users see and which requests still succeed when a given dependency fails, with and without a degraded mode.
- Choose a response for each dependency's failure — hide the feature, serve cached or default data, fail open or fail closed — and avoid fallbacks that are rarely exercised or move the load elsewhere.
- Not true: If any part of a page can't load, the whole request should fail.
- Not true: A dependency marked optional can never take the page down.
- Not true: Adding a fallback path always makes a service more available.
- Not true: When the cache fails, sending its reads straight to the database is a safe fallback.
- Not true: Graceful degradation is the same as load shedding.
- Not true: Failing open — carrying on without the dependency — is always the safer choice.
- Not true: Showing slightly stale data is always worse than showing an error.
- Not true: Users don't need to know when a feature is degraded.
- Not true: A circuit breaker on its own gives users a degraded page instead of an error.