Build fluency in the vocabulary of keeping an application usable when a non-critical dependency fails.
0 / 5 completed
1 / 5
At standup, a dev mentions designing a system so that when a non-critical dependency fails, the application keeps working with reduced functionality instead of failing entirely. What is this design principle called?
Graceful degradation designs a system so that when a non-critical dependency fails, the application continues working with reduced functionality, like hiding a personalized recommendation section, rather than failing entirely and showing the user nothing at all. Allowing any single dependency's failure to bring down the whole application means a relatively minor, non-essential component's outage causes a far larger impact than it should. This principle prioritizes keeping the application's core functionality available even when a secondary feature can't currently work.
2 / 5
During a design review, the team wants a page to render its core content immediately and fill in a slower, non-critical section afterward, rather than blocking the entire page on that slower section's completion. Which capability supports this?
Independent, non-blocking rendering lets a page's core content appear immediately, with a slower, non-critical section filling in afterward once it's ready, rather than blocking the entire page's render on that slower section's completion. Blocking the whole page on every section regardless of importance means one slow, non-essential dependency can degrade the experience of the entire page, including its core content. This independent rendering is a practical technique for actually achieving graceful degradation in a user-facing interface.
3 / 5
In a code review, a dev notices the code catches a failure from an optional third-party integration and falls back to a sensible default behavior instead of letting that failure propagate and break the whole request. What does this represent?
A fallback behavior for a failed non-critical dependency catches that failure and substitutes a sensible default, like an empty state or a cached previous result, instead of letting the failure propagate and break the entire request. Letting every dependency's failure propagate regardless of its actual importance treats a minor, optional integration's outage the same as a failure in a truly critical path. This deliberate fallback handling is what turns a potential full failure into a smaller, contained degradation of just the affected feature.
4 / 5
An incident report shows a third-party analytics integration went down, and because its failure wasn't isolated, it took the entire checkout flow down with it even though analytics had nothing to do with completing a purchase. What practice would prevent this?
Isolating a non-critical dependency's failure so it can't cascade into blocking a genuinely critical flow, like checkout, ensures an outage in an unrelated, optional integration doesn't take down core functionality that has nothing to do with it. Treating every dependency as equally essential means a minor component's failure gets an outsized, unjustified impact. This isolation, clearly distinguishing what's actually critical from what's not, is the core discipline behind designing a system for graceful degradation in the first place.
5 / 5
During a PR review, a teammate asks why the team builds a fallback for this non-critical dependency instead of just letting the whole request fail if that dependency is unavailable. What is the reasoning?
Letting the whole request fail whenever any dependency is unavailable, even a genuinely non-critical one, means a minor, unrelated outage causes a far bigger impact on the user than the actual severity of that outage warrants. A fallback lets the application keep working with reduced functionality instead, preserving the core experience. The tradeoff is the added implementation effort of identifying what's genuinely non-critical and designing a sensible, well-tested fallback behavior for when it fails.