Genuine Independence: The Discipline of No Shared Fate

A recovery site is a promise: if the primary fails, this will still be standing. The promise holds only if the two are genuinely independent — if there is no single failure that can take both at once. The failures of this promise travel under one name: shared fate. And shared fate is responsible for a remarkable share of the disasters where the elaborate recovery architecture turned out, at the decisive moment, to be no help at all.

The seductive thing about shared fate is that it hides. On the diagram, the two environments look separate. They have different names, sit in different boxes, perhaps different regions. The dependency they share is not on the diagram because it lives a layer below the boxes, in the infrastructure everyone assumed was 'just there.' The primary and the standby draw power from the same substation. Or they sit in different buildings but route through the same network provider, so a single fibre cut isolates both. Or, most modern and most common, they run in different regions of the same cloud but authenticate through one identity service, deploy through one control plane, or resolve names through one configuration store — and when that shared component fails, both regions go dark together, each holding a perfect and perfectly useless copy of the other's data.

The way you find shared fate is to interrogate the backup relentlessly with a single question: what does this share with the thing it is protecting? Ask it about every layer. Do they share power? Cooling? Physical location, or a location close enough that one flood, fire, or storm reaches both? Do they share a network path, a provider, a single point where traffic converges? Do they share an account, a set of credentials, an administrative console — so that a compromised login or a fat-fingered deletion can reach both at once? Do they share a software dependency: the same base image, the same certificate authority, the same message broker, the same deployment pipeline? Each 'yes' is a thread of shared fate, a way the two are secretly one. The goal is not to eliminate every shared thread — some are impractical to sever — but to know exactly where they are, so that none of them is the load-bearing wall your entire recovery stands on unwittingly.

Some forms of shared fate are subtle enough to deserve naming individually. The first is the shared blast radius of a mistake or an attack. Two regions can be perfectly independent against hardware failure and still share fate against a bad deployment: if the same automated pipeline pushes the same broken change to both, they fail in the same second for the same reason, and the second region protected you from nothing. Independence must include independence from your own actions, which is why staggered deployment — changing one environment, watching, then the other — is a continuity practice and not merely an operational nicety. The second is the shared dependency you did not build and cannot see: a third-party service, a public certificate authority, a domain registrar, an upstream provider that both environments quietly rely on. You did not choose to couple your regions through that provider, but you are coupled all the same, and the only defence is to know the dependency exists and to have thought about what you do when it fails.

Data replication deserves a specific warning here, because it is where shared fate turns most treacherous. Synchronous replication — copying every write to the second site before confirming it — gives a superb recovery point, close to zero. But it also couples the two sites tightly: a corruption, a malicious deletion, or a bad migration applied to the primary is faithfully and instantly replicated to the standby. The copy is perfect, which is exactly the problem — you have two perfect copies of the ruined data. Genuine independence therefore requires not only a geographically separate replica but a copy that is offset in time or otherwise protected from propagated corruption: a backup that logical damage cannot reach because it is not continuously connected, or point-in-time recovery that lets you rewind to before the damage. Protection against a data centre burning down and protection against a bad command are different problems, and a design that solves only the first while assuming it has solved both is the kind of confident, well-diagrammed plan that fails loudest.

The underlying principle is simple to state and endlessly tempting to violate: a recovery capability is only as independent as its least independent dependency. You can build two flawless regions and couple them fatally through one shared identity provider, one shared pipeline, one shared account. Independence is not a property of the boxes; it is a property of the whole graph beneath them. Trace the graph, name every shared thread, and decide deliberately which ones you can live with. The disaster will trace that graph for you if you do not — quickly, thoroughly, and at the one moment you most needed the answer already in hand.