Having a backup usually feels reassuring. A second supplier, another connection, an alternative system or an emergency route all suggest that if something goes wrong, there is somewhere else to turn.
But having two options does not always mean having two independent options. Sometimes the backup depends on many of the same things as the system it is supposed to replace. That dependency may sit several layers underneath and remain largely invisible during normal operation.
This month's bulletin looks at what happens when redundancy exists on paper but is weaker in practice.
Most of us understand redundancy in fairly simple terms. If one thing fails, another takes over.
A business might use two internet providers. A hospital might have backup power. An organisation may store data in more than one location. A manufacturer might maintain relationships with several suppliers.
Each arrangement appears to reduce dependency. And often it does.
The difficulty comes when we look underneath those arrangements. Two internet providers may use the same physical infrastructure. Two suppliers may rely on the same manufacturer further up the chain. Separate digital services may depend on the same identity platform or cloud infrastructure.
The alternatives are different at the point we can see, but further down they begin to converge. That is where redundancy can become fragile.
Imagine a company with two separate internet connections. The contracts are with different providers. The equipment is separate. If one provider experiences a problem, traffic can switch to the other. It looks like a sensible arrangement.
But both connections eventually pass through the same local fibre route. A major cable failure affects that route. Both connections disappear.
The company had two providers, but underneath them sat one dependency. Nothing about the original arrangement was necessarily wrong. The problem was simply deeper than the level at which redundancy had been measured.
The same pattern can appear elsewhere. Two cloud environments might share the same identity service. Two logistics routes might depend on the same port. Several suppliers might source a critical component from the same manufacturer. Backup generators might be independent of the electricity grid but dependent on a fuel supply that becomes difficult to maintain during a prolonged disruption.
In each case, redundancy exists. The question is how far that redundancy actually extends. The foundational study on Fragile Redundancy develops this pattern in greater detail.
This is where resilience becomes harder to judge. Visible alternatives are relatively easy to count. Hidden dependencies are not.
An organisation can know that it has three suppliers without necessarily knowing whether all three depend on the same upstream producer. It can operate multiple systems without immediately seeing the infrastructure they share underneath. And it can maintain backup arrangements that work perfectly during routine failures but behave very differently during a larger disruption.
That does not make redundancy pointless. Far from it. A second connection can protect against a provider outage. A backup generator can protect against a local power failure. An alternative supplier can help when another cannot fulfil an order.
The important distinction is that different backups protect against different kinds of failure. A backup does not automatically protect against everything that could affect the primary system.
That sounds obvious when stated plainly, but the underlying dependencies are not always obvious when systems are operating normally.
There is another reason this matters. Modern systems rarely exist in isolation.
Different organisations increasingly depend on common digital infrastructure, communications networks, logistics systems, specialist suppliers and technical expertise. As those shared layers become more important, systems that appear separate at the surface can become closely connected underneath.
This creates an interesting tension. We can add more backups while simultaneously becoming more dependent on the infrastructure those backups share. The number of alternatives increases, but their independence may not increase at the same rate — a shape examined in the study on Dependency Concentration.
That matters in critical systems because two backups offer much less protection if the same problem can cause both of them to fail.
Perhaps the useful question is not simply: do we have a backup? It is: what does our backup depend on? And then, one level further: what does that dependency rely upon?
Following that chain can reveal a very different picture from the one visible at the surface.
Sometimes the result will be reassuring. The alternative really is independent. Sometimes it will reveal shared dependencies that are difficult or impossible to remove.
Neither result automatically tells us that a system is resilient or fragile. But it gives us a more realistic understanding of what the backup can actually protect against.
Redundancy remains one of the basic ways systems protect themselves from failure. The presence of a backup, however, tells us only part of the story.
What matters is not simply how many alternatives exist, but how those alternatives are connected underneath. Sometimes two apparently separate systems eventually lead back to the same place.
Understanding where that happens can tell us considerably more about resilience than simply counting the number of backups available.
Future bulletins will continue to explore these less visible relationships across critical systems.