What is the Fallback pattern and how does it relate to the Circuit Breaker?

The Fallback pattern provides an alternative response path when a downstream call fails — whether due to a timeout, an exception, or a Circuit Breaker (Q25) in the Open state. Instead of propagating a hard error to the caller (and potentially all the way to the user), the fallback returns a degraded but functional result that lets the system continue operating at reduced capability.

Common fallback strategies:

• Cached response — return the last successfully retrieved value from a local or distributed cache. Works well for product catalogs, user preferences, and feature flags where slightly stale data is acceptable.
• Default/stub value — return a sensible default. An unavailable recommendation engine falls back to a static "top-10 bestsellers" list.
• Degraded feature — disable the feature entirely and return a response that omits the failed component. A loyalty-points display is hidden rather than blocking the checkout page.
• Alternate service — route to a secondary service (e.g., a read replica, a lower-SLA provider, or a local fallback implementation).

Relationship to Circuit Breaker: The Circuit Breaker detects failure and short-circuits calls. The Fallback defines what to do when the circuit is open (or any call fails). They are complementary: the circuit breaker decides that the call should not be attempted; the fallback provides the alternative response. Resilience4j, Hystrix, and similar libraries allow both to be configured on the same decorated method.

A fallback should never do expensive work — it must return quickly. If the fallback itself can fail, it needs its own timeout and should itself degrade gracefully. A fallback that calls yet another slow service is an anti-pattern.