LANDMARK · 6 MIN · BUILD
Fallbacks and graceful degradation
After this landmark, you can design a fallback path for an AI feature so a model outage degrades the product gracefully instead of breaking it outright.
↗
This concept is shared, but the Everyday lens is less central here.
You can still explore it. We’re showing the shared explanation and a related practical view without hiding the knowledge.
AI model providers have outages, rate limits, and latency spikes like any external dependency, but teams that would never ship a payment feature with no fallback for a down payment processor sometimes ship an AI feature with no fallback for a down model API. A resilient design has a plan for each failure mode: a timeout with a clear message rather than an infinite spinner, a secondary model or provider to fail over to for critical paths, and a degraded-but-functional mode (cached results, a simpler rule-based response, or clearly telling the user the feature is temporarily unavailable) rather than a broken page.
This is the canonical concept. It stays the same across learner lenses so personalization never changes the underlying facts.
◌ EVERYDAY LENS
What this looks like for you
When an AI feature you rely on suddenly errors out or hangs, that’s usually a fallback gap, not a fundamental limit; well-designed products would degrade to something useful instead of failing outright.
MAKE A DECISION
An AI-powered search feature on a retail site calls a third-party model API. That API has an outage during a high-traffic sale. What should happen?
CARRY THISFor one AI feature in a critical path you build or rely on, write down what currently happens if the model API times out. Is that the behavior you’d actually want?