Application reliability is about bounding uncertainty and work. Remote calls can be slow, duplicated, rejected or partially successful. Processes can restart while work is in flight. Queues can grow faster than consumers drain them. Caches can disappear. A useful pattern therefore needs an explicit trigger, a bounded action, an observable result and a recovery path.
For Application Reliability Patterns Mental Model, focus on failure containment, bounded work, explicit contracts, recovery. Decide which layer owns the behavior. If the same concern is independently implemented by the client, service mesh, SDK and application, the combined effect may be very different from what any one configuration suggests.
Production design
Define the user outcome. What must remain correct or available when this failure occurs?
Set a bound. Time, attempts, concurrency, queue depth, memory or stale-data age must have an explicit ceiling.
Preserve correctness. A fast degraded answer is useful only when it does not violate business invariants.
Expose state. Instrument the original traffic separately from retries, rejections, fallbacks and recovery attempts.
Design recovery. Know how the component returns to normal and whether recovery itself creates a traffic spike.