A currency-conversion microservice occasionally fails. A developer adds a fallback that returns a hardcoded exchange rate of 1.0 (treating the foreign amount as if it were already in the local currency) whenever the call fails, so the checkout flow never breaks. What's wrong with this specific choice of default value, and what would be a safer approach?

## What a default-value fallback is A **default-value fallback** is the simplest form of degradation: when a call fails, instead of propagating the error, the code substitutes a fixed, precomputed, or hardcoded value and continues as if the call had succeeded. Mechanically this is usually a single line — a catch block, a null-coalescing operator, or a config-driven default — which makes it tempting to add casually. The value returned can be: - a genuinely reasonable stand-in (e.g. defaulting a missing 'estimated read time' to a rounded average), or - as in this scenario, a value that happens to keep the code path running but has no real relationship to the true answer. ## Why defaults exist Defaults exist to keep a request completing rather than throwing when a non-essential field is unavailable, and they're extremely cheap to implement — no cache infrastructure, no retry logic, just a constant. For genuinely optional or cosmetic fields (a missing avatar, an unset nickname, a recommendation score), a default is often the right level of investment; building cache-based fallback infrastructure for it would be over-engineering. ## The trade-off The trade-off is between **engineering simplicity** and **correctness risk**, and the risk scales directly with how much the value matters downstream. - A default of `0` for a display counter is harmless. - A default of `1.0` for an exchange rate, or `true` for an 'is this address valid' check, or `0` for a shipping cost, directly changes money, legal compliance, or physical fulfillment outcomes. And because the fallback path returns a normal-looking, well-typed value rather than an error, none of the normal error-handling/alerting downstream ever fires. The system looks entirely healthy from the outside while quietly doing the wrong thing. This is strictly worse than a stale-cache fallback, which is at least usually close to correct; an arbitrary constant default has no such guarantee. ## How it fails in production In production this shows up as a slow-burning financial or trust incident rather than a visible outage: the fallback rate of 1.0 fires for some fraction of foreign-currency checkouts over days or weeks, generating either a wave of customer complaints about wrong charges or, worse, a wave of self-inflicted losses that finance discovers during reconciliation, long after the root-cause window has passed. Because the failure is invisible in logs that only track errors, it's frequently caught only through anomaly detection on business metrics rather than engineering monitoring, which delays diagnosis. A related failure mode is **scope creep**: a default that was reasonable when first added silently becomes load-bearing years later after the 'temporary' fallback is forgotten and the underlying service's reliability degrades. ## The safer pattern The safer pattern for correctness-critical values is to distinguish **'fail open'** from **'fail closed'** and pick deliberately per field rather than defaulting to fail-open everywhere for convenience: | Choice | When it applies | |---|---| | 'fail open' | proceed with a default, acceptable for optional data | | 'fail closed' | reject/hold and surface an error, required for financial/legal/safety-critical data | For the exchange-rate case specifically, a defensible fallback is the last known good rate served for a strictly bounded window (e.g. under 5 minutes old) with the response tagged as using a cached rate, or, if no sufficiently fresh rate exists, declining to complete that specific step and asking the user to retry, rather than inventing a number. Payment processors and banks operationalize exactly this distinction: currency conversion and pricing calculations are typically fail-closed (the transaction is held or declined rather than guessed), while things like an estimated delivery date or a 'customers also viewed' list are fail-open with a generic default, because the cost of being wrong is asymmetric between the two.