Fault Tolerance Problem Frame

Fault tolerance shows up to users as inconsistency in behavior, not as a neat binary of up or down. A partial outage can still return 200 responses while features silently degrade, or it can keep core features working while everything feels slow because requests pile up behind a dependency.

Perceived reliability is dominated by how long the bad experience lasts. When recovery takes minutes instead of seconds, users hit retry, clients amplify load, caches churn, queues back up, and the system often becomes harder to heal even after the original fault ends.

To make those user-visible outcomes concrete, interact with the scenarios below and notice how different symptoms change the user’s willingness to keep trying.

The same underlying fault can produce very different experiences depending on which component fails and how the system reacts. Error spikes are obvious, but timeouts often feel worse because they block user workflows while consuming server capacity, and stale reads can be acceptable or catastrophic depending on the feature.

A minimal system and its fault boundaries

Most fault tolerance discussions get clearer when you pin failures to a small set of components and the boundaries between them. In a minimal production setup, a client calls a stateless service, the service reads and writes a datastore, and performance depends on whether the request path hits a cache or waits on a slower dependency.

Use the diagrammed skeleton to identify where requests can stall, where state can be lost, and where backpressure should cut load before it spreads.