A recommendation service is unavailable during a high-traffic period. Should the application show popular items, cached recommendations, results from an older model, or nothing at all?
Show the full answer Hide the answer
The fallback ladder
The principle is degrade the quality of the answer, not the presence of the answer — and do it in stages, because different users have different amounts of usable fallback data.
- Cached recommendations for this user. Slightly stale personalisation is nearly indistinguishable from fresh personalisation for most users. This should cover the majority of active users and is the highest- quality fallback available.
- Recommendations from a cheaper, always-available model — for instance one using only signals already present in the request, with no feature-store lookup.
- Popularity or trending content, segmented by whatever coarse context is available (locale, followed communities). Not personalised, still useful.
- A curated default set, statically generated and requiring no dependency at all.
Why "nothing" is usually wrong
An empty section is a broken product. Users do not interpret it as "the recommendation service is degraded"; they interpret it as the product being broken or having nothing for them. For a discovery-driven product, the recommendation surface is the product, and showing nothing is close to being down.
The exception is where a wrong answer causes harm — a medical, financial or safety-critical recommendation. There, an honest absence beats a low-confidence guess, and that distinction is a product decision, not a technical one.
Why "older model" is not automatically right
An older model is a fine fallback if it is deployed, warm and independently available. Frequently it is none of those — it shares the same serving infrastructure, the same feature store, and therefore the same failure. A fallback that shares a dependency with the primary is not a fallback.
The fallback must fail independently. That is the property that matters, and it is worth more than the fallback's quality.
What must be true for this to work
The fallback path is exercised continuously, not held in reserve. Serve a small percentage of traffic from it always, so it is known to work and its quality is measured. Fallbacks that are never run do not work — this is the single most common reason graceful degradation fails at the moment it is needed.
The degradation is observable. Metrics distinguishing "served personalised" from "served cached" from "served popular", so the business impact of degradation is measurable and the system's state during an incident is legible.
The user is not misled. No claim of personalisation when serving popularity, and no infinite spinner — a spinner converts a degraded experience into a broken one, because it consumes the user's attention and delivers nothing.
The generalisable rule
For any optional dependency, decide in advance: what do we serve without it, does that path share any dependency with the primary, and when did we last run it? A degradation plan that cannot answer the third question is a hypothesis.