When wiring a fallback for an open circuit breaker — say, returning a cached value or a default response instead of calling the failing dependency — what should that fallback avoid doing, and what can go wrong if it's implemented carelessly?

## What a fallback is A fallback is the code path invoked when a circuit breaker short-circuits a call — it's what the caller gets instead of the real response, and its design deserves as much scrutiny as the breaker's thresholds, because a badly built fallback can turn a contained, fast-failing incident into a bigger, quieter, harder-to-diagnose one. ## The hard constraint Mechanically, wiring a fallback means providing a function that runs in place of the protected call whenever the breaker is open (and often also when the call itself throws, independent of breaker state, depending on the library). Good fallback design starts from one hard constraint: **the fallback must not itself be able to fail slowly or expensively**, because if it can, you haven't actually solved the resource-exhaustion problem the breaker exists to solve — you've just moved it one level down. Concretely, this means a fallback should read from something already resident and fast: - an in-memory cache, - a static default, - a value computed from data already in hand, rather than reaching out over the network to a different remote resource, and especially never to the same dependency that just failed or to another dependency that shares the same failure domain (same database, same downstream, same infrastructure). ## Why the pattern exists The reason this pattern exists is straightforward: a breaker without a fallback just converts a slow failure into a fast failure — the caller still gets an error, just quickly. A fallback goes one step further and lets the system **degrade gracefully** instead of failing outright: - a product page can show 'reviews temporarily unavailable' instead of a blank error page, - a recommendation widget can fall back to a generic 'popular items' list instead of disappearing, - a pricing service can serve a slightly-stale cached price instead of blocking checkout entirely. This preserves as much of the user-facing experience and business function as is honestly possible given a real dependency outage. ## Honesty versus availability The core trade-off is **honesty versus availability**. Serving stale cached data keeps the feature working, but if that staleness isn't surfaced anywhere — no flag, no log, no metric distinguishing 'served from fallback' from 'served fresh' — the team loses visibility into how often and how badly the dependency is actually failing, and worse, users or downstream systems may make decisions off data that's silently wrong (a stale inventory count showing an item as in-stock when it isn't, a stale price that no longer matches reality). The fix isn't to avoid fallbacks but to make them **observable**: emit a metric or log line every time the fallback path executes, and where the business case demands it, mark the response itself as degraded so downstream consumers can decide how much to trust it. ## Failure modes of a careless fallback Several concrete failure modes show up in production when fallbacks are wired carelessly. - **First**, a fallback that calls another service is a classic mistake — if that second service shares infrastructure, a connection pool, or simply correlates in reliability with the first (both behind the same overloaded load balancer, both hit by the same regional outage), the fallback fails right along with the primary path, and now the caller has no protection at all, just an extra hop of latency before the eventual failure. - **Second**, a fallback that does meaningful computation or I/O — writing an audit log synchronously, computing something expensive — can itself become slow under the exact high-concurrency conditions that caused the breaker to trip in the first place, since fallback invocation volume spikes precisely when the primary path is failing. - **Third**, over-broad fallback wiring — catching and falling back at too coarse a granularity, such as wrapping an entire checkout transaction in one breaker with one generic 'something went wrong, try later' fallback — can mask which specific step failed (payment vs inventory vs shipping calculation), making the resulting incident much harder to diagnose even though the user-facing symptom (a failed checkout) looks identical either way. ## A concrete real-world pattern A concrete real-world pattern: an airline's flight-search page wraps its call to a live pricing microservice in a circuit breaker whose fallback returns the last successfully cached price for that route, tagged with a 'price may be outdated, confirm on next step' notice, rather than either blocking the search page or silently presenting the stale price as authoritative. This preserves the ability to browse and compare flights during a pricing-service incident, avoids a second network call to another potentially-struggling service, and is honest with the user (and with the team's monitoring) about the fact that a fallback is in play rather than fresh data.