Skip to content
Software Architecture Guide

Graceful Degradation

Explanation

Section titled “Explanation”

Graceful degradation is an availability tactic. Availability means the system stays usable (see the article Availability). This tactic improves availability of the whole system. It preserves the most important functions during failures (f2).

Core idea. When a dependency becomes unavailable, a component keeps doing its core job. It may serve slightly stale data, alternate data, or even no data (f1). A local failure then hurts the system as little as possible (f1).

Rank features first. The tactic needs features ranked by criticality. A core set must stay up. Optional features can pause (f7). Deciding what counts as core is a business discussion as much as a technical one. For example, the business may have to weigh consistency against availability (f3).

What degradation looks like.

  • Show the rest of a page when one upstream system fails, instead of an error page (f4).
  • Turn off or reduce nonessential features so essential ones keep resources. A video app can drop to a lower resolution. This trades completeness for availability (f10).
  • Return default or cached responses and tell users that some data is temporarily unavailable (f12).
  • Suspend a less critical feature under load, then re-enable it when usage drops (f11).

Related mechanisms. arc42 separates three ideas (f8):

  • Feature degradation drops whole features.
  • Load shedding and rate limiting drop requests by priority.
  • A circuit breaker cuts off one failing dependency. Feature degradation decides what users still see afterward.

A circuit breaker can trigger graceful degradation. Pair it with automatic recovery so the system heals itself (f13). Alerts can notify operations (f12). Operators can also disable non-vital functions by hand with a kill switch, which works like a manually operated circuit breaker (f14).

Testing. Degradation requirements can be tested and verified (f3). The paths taken during a failure must be tested (f5).

Example

Section titled “Example”

An online shop’s product page depends on a recommendations service. The service goes down. The page still shows the product, price and buy button. The recommendations area shows a short notice or cached suggestions. Buying keeps working. When the service returns, the area switches back on.

Trade-offs

Section titled “Trade-offs”

Degradation adds work. Each degradable feature needs a fallback path, a health signal, and logic to re-enable it (f9). Fallback paths must be tested and be much simpler than the primary path. AWS also cautions that fallback strategies should generally be avoided (f5).

Users may read a missing feature as a bug unless the system signals the degraded state (f9). Cached or default values can also diverge from the real ones (f9).

AWS lists common mistakes:

  • Not identifying the core business functionality.
  • Not testing components during dependency failures.
  • Serving no data when partial results are possible (f6).

Degradation flow: core features keep running, optional ones pause until recovery.

Diagram source 
flowchart TD
  A[Dependency fails] --> B{Feature critical?}
  B -- Yes --> C[Keep running, use stale or alternate data]
  B -- No --> D[Disable or reduce feature]
  D --> E[Tell users and alert operations]
  C --> F[Dependency recovers]
  E --> F
  F --> G[Re-enable feature]

Checks

Section titled “Checks”
  • Features are ranked by criticality, with a core set that must stay up and optional features that can pause.
  • The business has agreed which function is core when not all requirements can be met.
  • Each degradable feature has a documented fallback path, health signal and re-enable logic.
  • Fallback paths are tested and are much simpler than the primary path.
  • The degraded state is communicated to users and operations, for example through a notice and alerts.
Section titled “Related”

Sources

Section titled “Sources”