Graceful Degradation and Fallbacks

Design each feature's fallback before you need it: cached or stale data, defaults, simpler algorithms, hiding optional sections, read-only mode, or queuing writes for later. Use feature flags as kill switches to turn off expensive features under load. Fallbacks must be cheap and tested — a fallback that calls another fragile service is not a fallback.

Degradation plan examples

TypeScript

export async function productPage(id: string) {
  const product = await products.get(id);                                     // critical
  const [reviews, recs] = await Promise.allSettled([
    withTimeout(reviewsClient.top(id), 200),
    flags.enabled("recommendations") ? withTimeout(recsClient.similar(id), 250) : Promise.resolve(null),
  ]);
  return {
    product,
    reviews: reviews.status === "fulfilled" ? reviews.value : null,          // hide on failure
    recommendations: recs.status === "fulfilled" && recs.value ? recs.value : await popular.cached(),
    degraded: reviews.status === "rejected" || recs.status === "rejected",
  };
}

Common pitfalls

• Fallbacks never exercised until an incident.
• Fallbacks hiding outages from monitoring (emit metrics).
• Degrading critical correctness (stale prices charged without recheck).

Key points

• Plan fallbacks per feature
• Kill switches via flags
• Test and monitor degraded modes

Further reading: AWS Builders' Library: Avoiding fallback in distributed systems