Risks that look independent tend to arrive together

Independence is the assumption doing all the work

The reason spreading a risk reduces it’s that the individual failures are supposed to be unrelated, so the chance of them all happening at once is the product of small numbers, which is a much smaller number. Every claim about diversification, redundancy or backup rests on that multiplication, and the multiplication is only valid when the events are genuinely independent.

When they are not, the arithmetic changes character completely. Two components that fail together for a shared reason are, for the purposes of a failure, one component with a decorative second name. The system has the appearance of redundancy and the reliability of a single point.

Where the shared cause hides

Common causes are usually mundane and usually invisible in the design documents. Two suppliers with different names sourcing from the same factory. Two servers in different racks on the same power feed. Two income streams from different clients in the same industry, which will cut spending in the same quarter. Two investments in different sectors that both depend on the cost of borrowing.

The pattern is that the correlation is created by something upstream of the things being counted, and the things being counted are what somebody looked at. Diversification is generally performed over the visible dimension — names, sectors, locations — while the dependency lives on a dimension nobody enumerated.

Correlation isn’t a constant

The most dangerous property is that dependencies strengthen under stress. Things that move independently in ordinary conditions frequently move together in bad ones, because the bad condition is itself the common cause. A shock large enough to matter tends to be a shock that reaches everything, and the historical record of quiet periods systematically understates how connected the parts are when it counts.

This is why a measure of correlation taken from calm data is close to useless for planning. The number you need is how these things behave in the situation you are protecting against, and by construction that situation is rare, so the data on it is thin. Anyone who quotes a precise figure for it is extrapolating from a small number of episodes.

A worked illustration, deliberately hypothetical

Suppose, purely as an arithmetic exercise with invented figures, that two systems each fail in one month out of a hundred. If failures were independent, both failing in the same month would happen about one month in ten thousand — rare enough to ignore. Now suppose that nine times out of ten, the cause of failure is a shared dependency. The joint failure rate rises to something close to the failure rate of one system alone, because the second system is mostly a copy of the first.

Those numbers are made up to show the shape of the sensitivity, not to describe any real system. The point is how violently the answer moves: a modest amount of shared cause destroys most of the benefit of duplication, which is why the honest question about any redundant arrangement is not how many copies exist but what they have in common.

How to find the shared cause before it finds you

The productive exercise is to work backwards from the failure rather than forwards from the components. Assume both parts are down and ask what single event could have done that. The answers come quickly once the question is posed this way, and they are usually infrastructural: power, network, a person, a document, a supplier, a jurisdiction, a piece of weather.

The second exercise is to list the dimension along which you diversified and then name three other dimensions you did not. If you spread across companies, ask about geography. If you spread across geography, ask about the customer base. There is no complete list, and the aim is not completeness but to break the habit of counting only the dimension that was easy to count.

What to do when the correlation cannot be removed

Sometimes the dependency is unavoidable, and the honest response is to stop calling the arrangement redundant and to size the exposure accordingly. A backup that shares a failure mode with the primary is still useful for the failures it doesn’t share, which is most of them; it simply provides no protection at all for the one that matters most.

The other response is to hold something genuinely uncorrelated, which nearly always means holding something inefficient. Reserves, slack, a second method that is slower, a relationship you don’t currently need. These look like waste in every quiet period, and the quiet period is when they get cut, which is a fair description of how most correlated failures become possible in the first place.