Graceful Degradation

The All-Or-Nothing Trap

 page loads require: recommendations + reviews + inventory +
 ads + profile. ONE fails → whole page 500s?

 users experience: NOTHING WORKS.
 reality: 80% of value was still deliverable.

 GRACEFUL DEGRADATION: every dependency failure has a
 PRE-DESIGNED diminished mode:

 recommendations down → show popular/trending instead
 reviews down        → collapse section ("unavailable")
 inventory check slow → show cached stock + "confirm at cart"
 ads down            → whitespace (page loads FASTER!)

The Degradation Ladder Per Feature

 design each feature's ladder BEFORE incidents:

 PRODUCT PAGE:
   L0 full:      live recs, reviews, live inventory, personalization
   L1:           cached recs, reviews, live inventory
   L2:           no recs, no reviews, cached inventory w/ warning
   L3 static:    CDN-cached core content only
   L4 fail:      branded error page (still fast, still branded)

 each rung = a deliberate engineering artifact:
 caches with long TTLs, default-content services,
 static fallbacks. degradation is BUILT, never improvised.

Feature Flags as Degradation Controls

 runtime switches to shed complexity on demand:

 flags: recs.enabled, reviews.enabled, search.v2

 incident playbook becomes: flip flag → instant load reduction
 → diagnose calmly → restore.

 requirements for flag-based degradation:
 □ kill switches tested REGULARLY (untested switch =
   surprise during emergency — the worst time)
 □ flips take effect in SECONDS (not next deploy)
 □ dashboards show per-flag load contribution
 □ defaults safe: unknown state → degraded-but-working

What Must NEVER Degrade Silently

 graceful ≠ dishonest. integrity boundaries:

 ✗ showing stale PRICES silently (legal/trust exposure)
 ✗ fake "in stock" from cache without disclaimer
 ✗ accepting orders when payment capture is down
   (queue them visibly: "order reserved, confirming payment")
 ✗ auth "fallbacks" that skip verification

 rule: degrade the EXPERIENCE, never the CORRECTNESS of
 money/identity/commitments. surface uncertainty honestly.

Dependency dies	User sees	Never acceptable
Recommendations	popular items	blank page
Reviews	section hidden	error modal
Inventory service	cached+disclaimer	wrong silent answer
Payment gateway	queued-order message	silent charge attempt

Interview Framing

“Design the product page to survive any single dependency failing” scored shape: enumerate dependencies with per-dependency fallback table, degradation ladders for the critical two, kill-switch infrastructure mentioned, correctness-boundary statement (money/auth never fake-succeed), and testing note (chaos-drill the fallbacks). Pre-built fallbacks are what separates resilient designs from hopeful diagrams.