Graceful Degradation
Graceful degradation keeps the core job working when an optional dependency fails. The result may be smaller, older, or less detailed.
dependency failure -> safe reduced mode -> user notice -> observe -> restore full modeSEARCH✓workingCART✓workingRECOMMEND−temporarily hiddendependency failure -> safe reduced mode -> user notice -> observe -> restore full modeSREAnother example
The recommendation service fails. Search, product pages, and the cart still work. The page hides recommendations and explains the temporary change.
Main parts
- 01Core user job
- 02Optional dependency
- 03Failure detector
- 04Safe reduced result
- 05User notice
- 06Recovery check
Use it when
Use it when the core user job stays safe without an optional dependency. Define the reduced result, notice, test, and recovery path.
Do not use it when
Do not degrade a payment, permission, or safety check when missing data makes the answer unsafe. Never label stale data as current.
Name used in code
dependency failure -> safe reduced mode -> user notice -> observe -> restore full mode Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Graceful Degradation for this system while keeping data correct, secure, and easy to operate. User context: The recommendation service fails. Search, product pages, and the cart still work. The page hides recommendations and explains the temporary change. Technical concept or control: Graceful Degradation. Why it fits: Use it when the core user job stays safe without an optional dependency. Define the reduced result, notice, test, and recovery path. Do not use it when: Do not degrade a payment, permission, or safety check when missing data makes the answer unsafe. Never label stale data as current. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Graceful Degradation. Definition: Graceful degradation keeps the core job working when an optional dependency fails. The result may be smaller, older, or less detailed. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.