Why a system with no single point of failure fails together

Three availability zones, two providers, four replicas. Then a certificate authority, a DNS resolver or a configuration service used by all of them returns an error, and every independent path fails within the same ninety seconds.

What everyone sees

Independence is treated as an architectural property established by separating components. Separation at one layer does not establish it, because components separated above can converge below — on a shared library, a shared identity provider, a shared clock or a shared control plane that nobody drew because it was not part of the design.

What is actually happening

Buldyrev, Parshani, Paul, Stanley and Havlin analysed interdependent networks and showed that coupling between systems produces abrupt cascading collapse at much lower failure thresholds than either network exhibits alone, with the transition being discontinuous rather than gradual. Vespignani’s discussion of the same result emphasises that the fragility comes from the interdependency itself rather than from weakness in any component, so hardening individual parts does not remove it. The practical translation is that redundancy protects against the failure modes it was designed against and provides nothing against a dependency common to every redundant path — and the common dependency is usually the one that is too boring to appear on the diagram.

Why it stays hidden

The shared dependency hides because it is reliable. A component with years of uninterrupted service is not treated as a risk, is not included in failure planning, and often is not owned by anyone in the organisation. Its very reliability is what allowed every independent path to be built on top of it without anyone noticing they had done so.