A product-catalog service starts timing out under load. The API gateway in front of it is configured to serve the last successfully cached response for each product page when that happens, with no expiry check during the outage. What risks does this introduce, and how would you bound them?

## What serving stale cache actually does Serving stale cache as a fallback means: - on a normal request, the system fetches fresh data and stores (or refreshes) a copy in a cache, or a separate 'last known good' store; - on a failed or timed-out call to the primary source, instead of propagating the error, the code reads from that last-known-good copy and returns it as if current, usually tagging it internally (and sometimes visibly) as stale. This differs from ordinary caching-for-performance in one crucial way: an ordinary cache respects a `TTL` and refuses/refreshes once expired, while a stale-cache fallback is deliberately used past its normal freshness window, specifically because the alternative — an error — is judged worse than showing old data. ## Why teams do it The reason to do this is that many kinds of data are 'good enough slightly wrong' — a product description, an image, a category listing rarely changes minute to minute, so continuing to show yesterday's version is strictly better for the user than a blank error page. It converts a hard outage of the origin into a soft, mostly invisible degradation for read-heavy paths, and it buys the origin system time to recover without every client request piling on with retries. ## The trade-off The core trade-off is **freshness versus availability**, and it is not free even when the data 'looks' harmless. - Prices, stock counts, and promotional flags are the **classic danger zone** — an item can sell out or a price can change between when the cache was captured and when a stale copy is served, and if the checkout flow trusts that same stale number, customers can be charged incorrectly or oversold. - There's also an **operational cost**: keeping a 'last known good' copy around indefinitely means more storage, and the cache warming/refill logic adds complexity that itself needs testing. - And once the primary recovers, if every client's cache is due to refresh simultaneously, the origin can be hit by a **'thundering herd'** of near-simultaneous refill requests right as it's coming back up, causing a second wave of failure. ## Failure modes in production 1. **Unbounded staleness** — in production, the most common failure: without a hard ceiling on how old a stale-fallback response is allowed to be, an extended outage (hours or days) results in customers silently browsing an entire storefront frozen in time, with no visible signal anything is wrong — support tickets pile up before anyone notices the metric. 2. **A second failure mode is stale data leaking into a path that assumed freshness** — e.g. a stale 'in stock: yes' flag reaching the add-to-cart button, resulting in overselling that has to be resolved with refunds. 3. **A third is the thundering-herd recovery problem**, where the fallback mechanism itself becomes the cause of a second outage when the primary comes back online and every stale entry tries to refresh at once — mitigated with jittered/staggered refresh and stale-while-revalidate patterns rather than a synchronized cold refetch. ## How the caching layer bounds it CDN and HTTP caching define this formally via the `stale-while-revalidate` and `stale-if-error` `Cache-Control` directives from RFC 5861: `stale-if-error` explicitly tells a cache 'if the origin errors or times out, you may serve this stale response for up to N seconds instead of surfacing the error,' which is exactly the fallback-on-timeout behavior described in the scenario, with the bound (N seconds) baked into the contract. Content platforms like news sites and e-commerce catalogs commonly configure this at the CDN/edge layer so that when an origin has a bad deploy or a database blip, readers still get yesterday's homepage instead of a 502, while the staleness window is capped to something like 5 to 30 minutes so the blast radius of wrong data stays small and self-correcting once the origin heals.