This trace follows the actual state transitions behind the companion Reliability Comes From Explicit Failure Behavior. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Name a dependency failure
An unreliable component does not make a system unreliable if the system contains and recovers from its failure. Reliability design starts by naming failure modes, their blast radius, detection signals, and the behavior users should see when a dependency is unavailable.
Step 2: Bound waiting with a deadline
If a recommendation service fails, a commerce application might continue checkout without recommendations. That fallback preserves a core transaction while degrading a secondary feature. A timeout bounds waiting; a circuit breaker can stop repeated calls during an outage and permit controlled recovery probes.
Step 3: Choose safe degraded behavior
If an optional recommendation service fails, let the core transaction continue with recommendations omitted; a fallback must preserve the product’s safety and correctness contract.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Stop repeated harmful calls
Redundancy helps only when failure modes are sufficiently independent and failover is tested. A fallback can return incorrect or unsafe data if its contract is vague. Availability targets also need a measurement window and an explicit definition of a successful request.
Step 5: Detect and restore service
For a service that depends on a payment provider and a recommendation service, classify which outage should block checkout and what degraded mode is safe for each dependency.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.