Structure instead of time

Why is the dependency graph that governs failure not the one on the architecture diagram?

CaseConstructed case · Selin at Wayhop

An optional call took booking down

Three incidents in one quarter, each with a puzzle.

The optional "ride again?" recommendations call slows down to 10 seconds per call. Within two seconds the booking service stops answering all requests, including requests that never use recommendations. Booking was "never supposed to depend" on recommendations.
A configuration change reaches all 40 cities in four minutes, and every city fails at once. A month later an internal certificate expires, and every instance of the service stops working in the same second. Wayhop has 3 replicas in each of 3 zones and plenty of capacity.
A whole availability zone (one data center of the cloud region) fails. The runbook says "autoscale in the surviving zones". The autoscaler never finishes the job, because it is itself overloaded by the same event.

The three puzzles share one cause: the dependency graph that governs failure is not the one on the architecture diagram.

How it ends →

Feedback loops and Metastable failure held the system fixed and watched time: gain, delay, equilibria. This article drops time almost entirely and looks at structure. The question is no longer "does this loop diverge?" but "what set of things fails together, and is it the set you provisioned against?"

The new constraint is the dependency graph, and the important property of that graph is that it is not the one on your architecture diagram. The diagram shows calls. The graph that governs failure also contains every shared resource, every common artifact, every implicit dependency on DNS, on a certificate, on a clock, on a configuration store, on one team's deploy pipeline. Correlation lives in the edges nobody drew.

What stops mattering is the loop. Nothing here needs positive feedback: a cascade propagates once, cleanly, and is devastating without amplifying anything. What starts mattering is an arithmetic you have been using implicitly all along, availability composition, and its one load-bearing assumption.

Redundancy multiplies availability only under independence, and every mechanism that makes redundancy affordable (sharing, standardizing, automating) manufactures correlation.