Graceful degradation deliberately limits features during a failure while preserving a safe, useful part of the service. It begins by separating essential functions from optional ones, rather than ignoring errors.

Example

Practice-inspired educational scenario: a document was generated, but saving an optional copy failed. The user can still read and download the document. Separate the two outcomes: “Your document is ready. The copy was not saved.”

Design the boundary

  1. Define success for the core operation and identify features that may be limited.
  2. Bound dependency waits so an optional feature does not block the entire response.
  3. Preserve the available result and clearly disclose the limitation.
  4. Monitor failure and recovery without recording confidential content.

What does this not solve?

It does not guarantee that a copy will be saved later. That needs a separate durable mechanism and error handling. It also does not replace resource isolation: if an optional feature exhausts a shared connection pool, catching an exception may not protect the service.

Mandatory functions are different

An order requiring durable storage is not successfully accepted just because a screen displays confirmation. Access control cannot simply be skipped during a failure either. Requirements establish what can degrade and what must end in confirmed success or explicit failure.

Practise a storage failure → · Source: Azure — self-preservation and graceful degradation