Graceful Degradation

The art of returning a partial / cached / fallback response instead of failing.

Overview

Serve less instead of failing completely

Graceful degradation is the discipline of "serve less when you can't serve everything" instead of "fail completely." It is often the difference between an outage and a recoverable incident.

> [!WARNING] The anti-pattern is silent degradation that customers detect before you do. Always alert on degradation.

The three patterns

1. Cached fallback — Return the last-known-good value, often with a staleness header such as Cache-Control: max-age=0, stale-if-error=86400 — Search returns 5-minute-old results when the index is down; a cached user profile when the profile DB is down; last-known prices with a staleness notice
2. Partial response — Return what you have and omit the rest — Chronological feed without recommendations; product page without reviews; search results from healthy shards with a note
3. Default response — A sensible generic value when personalized data is missing — Global "most popular" list; the A/B control variant; the safe feature-flag value

The decision framework

For each downstream call, ask what to do when it fails.

Fail the request — Security checks, payment authorization, anything user-critical
Degrade — Enrichment data, recommendations, optional features
Skip — Logging, analytics, audit that is isolated from the user path

Most user-facing services mix all three: the auth check must succeed, recommendations can degrade, and analytics can skip silently.

Implementation patterns

Try / fallback structure:

Circuit breaker + fallback (resilience4j, Polly):

Service mesh sidecar fallback — Istio and Envoy can return a default response on upstream failure; fits "return 200 with empty body," not rich fallbacks
X-Degraded: recommendations header — Tells clients which features are degraded
X-Cache-Hit: true; X-Stale: true headers — Marks cached or stale data so UIs can show "Some data may be outdated"

Instrument every degraded path

Metric — requests_total{quality="full — degraded — fallback"}
SLI — % of requests served at full quality
Alert — Degraded above 10% of traffic for a sustained period

A service that silently degrades 50% of the time gives users a much worse experience than its SLO claims.

The product and engineering boundary

Engineering implements degradation; product defines what is acceptable. Financial settlement may demand "no degradation, fail loud," while a feed app welcomes "show what you can."

Full quality — Personalized feed with recommendations
Acceptable degradation — Chronological feed without recommendations
Unacceptable failure — Showing another user's feed

> [!TIP] Have the conversation explicitly and write the answer down per feature.

Key concepts

Cached fallback: Return last-known-good cached value when downstream is unavailable. With staleness headers.
Partial response: Return what you have; omit what you don't. Better than complete failure for non-essential data.
Default response: Sensible fallback when personalized data unavailable. "Most popular" lists, control variants.
Quality SLI: % of requests served at full quality vs degraded. Captures partial-failure invisible to availability SLI.
Header signaling: Response headers (X-Degraded, X-Stale) tell clients about degraded state; UIs can show notices.
Per-feature policy: Product + engineering decide per feature: must succeed, can degrade, can skip silently. Documented.

When to use it

Designing every external call — what's the fallback?
Reviewing user-facing services — does the experience degrade gracefully?
Postmortem — could degradation have prevented this outage?
Product conversations — explicit per-feature degradation policy

Interview questions

Walk me through how you'd design a feature with graceful degradation.
When should a service NOT degrade gracefully?
How do you avoid "silent degradation"?