Graceful Degradation

Overview

Graceful degradation is the deliberate design of lower-quality service levels. The system decides in advance what to drop, substitute, or simplify as dependencies become unavailable.

How it works

List the features of a request and rank them. Critical features fail the request; optional ones fall back.

product page
  price, stock      critical   -> fail request
  reviews           optional   -> cached copy, else hide
  recommendations   optional   -> global bestsellers
  personalization   optional   -> default layout

Each optional call has its own short timeout and breaker. When it trips, the handler returns the fallback and sets a degraded marker used for metrics and, where honest, UI hints. Recovery is automatic as the breaker closes.

Pitfalls

• Fallbacks that call another unhealthy service simply move the failure.
• Fallbacks are code that runs rarely. Test them with game days and fault injection.
• Serving stale data without bounds can violate business rules, so set maximum staleness.
• Hidden degradation hides outages. Emit metrics for every fallback used and alert on the rate.
• Caching a fallback response as if it were real can poison caches after recovery.

Key takeaways

• Decide criticality per feature before the incident.
• Prefer fallbacks that need no network, such as static defaults or local caches.
• Measure and alert on degraded responses.
• Test fallbacks continuously.
• Agree on degraded behavior with product owners in advance, because deciding what users see during an outage is a business choice and not only an engineering one.