Fallback
A failed dependency can block a specific user function entirely.
- TriggerTrigger: A defined failure path activates the substitute response.
- SubstituteSubstitute: A substitute provides limited functionality.
- DisclosureDisclosure: Users and operators can identify the substitute state.
Context
Why this is important
Protect specific functions with a deliberate substitute.
Protect specific functions with a deliberate substitute.
Fallback: inspect the decision
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. The shop serves recommendations from a cache while its recommendation service is unavailable. The fallback affects recommendations only; cart, price validation, and payment follow their own rules. The result carries a timestamp, and use of the cached value ends after five minutes. Monitoring counts fallback responses separately from normal ones. Once the dependency recovers, the normal path resumes.
This is how you read the picture
- Trigger Trigger
- Substitute Substitute
- Disclosure Disclosure
| Concept | Meaning | Review question |
|---|---|---|
| Trigger | A defined failure path activates the substitute response. | Which function continues during recommendation-service failure? |
| Substitute | A substitute provides limited functionality. | What must the cache fallback check? |
| Disclosure | Users and operators can identify the substitute state. | Why is the same fallback not automatically suitable for payment status? |
Benefits & limitations
Helps if:
- Protect specific functions with a deliberate substitute.
- Define permitted substitute data and maximum age for each function.
Boundaries
- A substitute path can return incorrect or misleading business data.
- A cache fallback can suit recommendations, but not automatically authoritative prices or payment status.
In practice
- Define which cached recommendation fields are acceptable as fallback and how their timestamp appears in the UI; keep price, cart, and payment status separate.
- Disable the recommendation service in a test and measure how long the cached value is used; check the five-minute limit and behavior for older data.
- Monitor fallback calls and errors separately from normal responses, and test whether the shop returns safely to the normal path after the dependency recovers.
Read the detailed explanation
A fallback selects an alternate path or substitute response when a dependency fails. It keeps a specific function usable, for example with a cached value or a reduced result.
The substitute must be valid for the business context and its origin must remain visible. Stale prices or incorrect authorization decisions can be worse than a clear error; fallbacks therefore need freshness limits and a recovery path.
The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. The shop serves recommendations from a cache while its recommendation service is unavailable. The fallback affects recommendations only; cart, price validation, and payment follow their own rules. The result carries a timestamp, and use of the cached value ends after five minutes. Monitoring counts fallback responses separately from normal ones. Once the dependency recovers, the normal path resumes. fallback degradation and graceful degradation help compare this decision with adjacent concerns.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which function continues during recommendation-service failure?
View the solution with justification
Recommendations are served from a cache with a defined freshness limit.
ApplyingTransferred to a new situation
What must the cache fallback check?
View the solution with justification
The value age and business validity, plus disclosure of the fallback state.
EvaluateWeighing an alternative
Why is the same fallback not automatically suitable for payment status?
View the solution with justification
Stale payment status could trigger a duplicate charge or a false order confirmation.
Explore further
These building blocks continue the thoughts of this page.
References
- Circuit Breaker pattern (opens in new tab)Describes substitute responses when a dependency fails.
- Transient fault handling (opens in new tab)Places error handling, retries, and protective mechanisms in context.
- Google SRE: Handling Overload (opens in new tab)Primary reference on overload responses and degradation strategies.