Two suppliers can share one failure.

Picture two invoices on a desk, from two different suppliers, for two systems that can each take a customer's order. Someone has written "independent" in the margin of the second, because that was the reason for signing it: if one supplier fails, the other keeps the orders coming. Clipped behind them is a diagram of how an order actually gets taken. There are two lines, one through each supplier. Near the bottom, both lines pass through a small box that neither invoice mentions: the service that checks who the customer is. Nobody bought that box on purpose. If it stops, both suppliers stop at the same moment, and for that failure the second invoice has bought nothing.

That diagram is the subject of this essay. Buying from two suppliers reduces some risks only if their paths to the outcome do not run through the same vulnerable component. Supplier diversity is a fact about contracts: how many companies you pay, and how many could fail commercially without taking you with them. Failure-path independence is a fact about the service: whether the things that must work for the outcome can fail separately, or only together.

My argument is that the second fact is the one a resilience claim depends on, and that it has to be drawn rather than assumed. The number of suppliers is useful information for procurement. It is not a reliability calculation. None of this makes a second supplier worthless. It protects against that supplier's own outages, its pricing and its exit, which is a different and real benefit. The point is to know which failures the second contract covers, and which ones it shares with the first.

Start from the outcome

The way to find the small box is to begin with what the customer is trying to do, not with the list of suppliers. Take a customer order. To complete it, a storefront must load, a checkout must accept the basket, a payment must clear, the customer must be recognized, and a record of the order must be written somewhere that will still have it tomorrow. Under those sit the name service that finds the storefront, the network that carries the request, the certificates that make it trusted, and the people who will fix any of it when it breaks.

Reliability belongs to that outcome, not to any one component. A storefront that loads perfectly cannot take an order if the sign-in behind it is down; from the customer's side, the order failed, and it does not matter that most of the system was fine. So the question for a second supplier is not "is it a different company?" but "which of the things the outcome needs does it replace, and which does it still share?" Usually it replaces some and shares others. The shared ones are where the two contracts can fail together.

Shared components hide well because they sit below the level at which things are bought. An organization buys a service boundary: an order platform, a payments service, a hosted database. It does not usually buy, or see, the storage service, identity provider or control plane that the service boundary is built on. Two suppliers can each be excellent, each be independent companies, and each run on the same cloud region or call the same identity provider. The contracts are separate. The failure is not.

A product boundary is not a failure boundary

Cloudflare's account of its outage on June 12, 2025, shows how this looks from inside a single provider.¹ For a little under two and a half hours, by the company's own count, a long list of its products failed or degraded. The cause was a failure in the storage infrastructure underneath Workers KV, a key-value store that many other Cloudflare products use to keep configuration and state. Part of that storage was backed by a third-party cloud provider, which had an outage of its own.

The postmortem is candid about the design. Workers KV was built as what Cloudflare calls a coreless service, meant to have no single point of failure, but it relied on a central data store as its source of truth, and when that store failed, cold reads and writes failed completely. The effects then spread to the products built on KV. Every identity-based login to Cloudflare Access failed. New WARP clients could not register. Every inference request to Workers AI failed. Logins to the company's own dashboard broke, by more than one route. Other parts of the network, including DNS, caching, the proxy and the firewall, were not directly affected.¹

From a customer's point of view, Access, WARP and Workers AI are different products. They solve different problems, appear on different lines of a bill, and may have been chosen by different teams. Underneath, they shared a component, and when it failed they failed together. Cloudflare does not hide behind its supplier: it writes that it is "ultimately responsible for our chosen dependencies."¹ Its remediation is aimed at the dependency, not the products: improving redundancy in KV's storage to remove the dependency on any single provider, reducing each product's exposure to single points of failure, and building tools to bring services back gradually so that recovery itself does not overload the system.¹

This is one company's account of one incident, not an audit, and it does not say the internet went down; most of Cloudflare's network kept working. Its value here is the mechanism. A buyer who had chosen two of these products to back each other up would have found no backup on June 12. And the same shape appears across companies, not only within one: two suppliers built on the same cloud provider, the same identity service or the same payment processor have a shared box whether or not either of them mentions it.

The arithmetic of a shared box

A deliberately simple model shows how much the shared box matters. Its numbers are invented for the illustration; they are not anyone's availability figures.

Suppose each of two paths to taking an order fails 1 percent of the time in some defined period, and suppose their failures are fully independent. Both fail together only when two 1-percent events coincide: 1 percent of 1 percent, or 0.01 percent. That is the promise behind the word in the margin, and if the paths truly are independent, it is a large improvement on a single path's 1 percent.

Now add a shared component that both paths need, and give it a 0.5 percent chance of failing in the same period, independently of the two branches. The outcome now fails in two ways: when the shared component fails, whatever the branches do, which is 0.5 percent; or when the shared component works but both branches fail anyway, which is 99.5 percent of 0.01 percent. Together that is 0.50995 percent. The arrangement fails about 51 times as often as the two-supplier promise suggested, and almost all of that risk is the one small box.

The model also shows what does not help. Add a third supplier through the same shared component, and the chance that all three branches fail together falls to one in a million. The total barely moves, from about 0.50995 percent to about 0.5001 percent, because the box is still there. Make the shared component itself more reliable, or give the paths a way to work without it, and the total falls sharply. Figure 2 lets you vary the shared component's failure chance while the branch assumptions stay fixed.

Why real systems are harder

The model is generous in one important way. It assumes that, apart from the one shared box, the two paths fail independently. Real systems are tied together by much more than a diagram shows. The two suppliers' administrators may sign in through the same identity provider. Their emergency changes may go through the same change process, or the same overworked engineer. Their traffic may cross the same network links. The tools a team needs to recover may themselves depend on the service that failed, and the people doing the recovery are the same people whichever supplier broke. Each of these makes simultaneous failure more likely than the arithmetic says. This is an inventory of possibilities to check, not a claim about what caused any particular outage.

The sociologist Charles Perrow gave these worries their most famous form. In Normal Accidents, first published in 1984, he sorted systems along two dimensions: whether their parts interact in linear, expected ways or in complex, unexpected ones, and whether they are loosely or tightly coupled.³ Where interactions are complex and coupling is tight, he argued, failures combine in ways no one designed for and spread faster than people can understand them, and adding more safety devices can add new ways to fail. The book is a lens, not a proof. It does not show that software outages are inevitable, and it does not show that redundancy is pointless. It does show why a second supplier, with its integration code and failover logic, is itself one more part that can interact with the others.

Engineering practice offers the counterweight. Google's site reliability book defines a cascading failure as "a failure that grows over time as a result of positive feedback," and spends a chapter on design and operational choices that stop the feedback: shedding load before a server collapses, serving degraded results rather than none, limiting retries so that a struggling service is not buried by its own clients, setting deadlines, and testing systems at their limits before an incident does it for you.² Coupling, in other words, is partly a design variable. A shared component that fails gracefully, and paths that can keep working without it for a while, turn a shared failure into a shared slowdown.

Choose the remedy for a named failure

Drawing the dependency is the start. The next step is to name, for each shared box, how it can fail, and then to choose a remedy aimed at that failure. There are usually three kinds.

The first is to remove the shared dependency: give one path its own way to recognize customers, its own storage, or a different provider underneath. This is the remedy the second contract was supposed to be, and it is often the most expensive, because the shared component was shared for good reasons of cost and simplicity.

The second is to degrade safely. If the identity service fails, perhaps the order path can accept guest checkouts, or queue orders for confirmation once sign-in returns. The outcome is worse, but it is not zero. Deciding in advance what the degraded version of the service is, and testing that it works, often buys more resilience than a new supplier.

The third is to rehearse a manual path: the phone line, the paper form, the spreadsheet that can take orders for an afternoon. It sounds old-fashioned. It is also the one path that does not share a control plane with anything, provided the instructions for it are not stored only in the system that failed.

Any of these may beat adding a third supplier that shares the first two suppliers' control plane. The economic question is which additional independence is worth paying for, against which named failure. Some shared risk will always be accepted. The difference between an accepted risk and a hidden one is that someone wrote the accepted one down.

Objections, considered

Complete independence is impossible. Agreed. Every system shares something with every other: the power grid, the internet's routing, the laws of the country it runs in. The goal is not to remove every shared institution or physical resource. It is a priced reduction in specified common failures, chosen because their consequences are large and their remedies affordable.

Multiple suppliers make operations harder. They do. Two suppliers mean two integrations, two sets of credentials, two support contracts and a failover that must itself be tested. That complexity belongs in the decision. More moving parts can offset the gain they were meant to buy, which is Perrow's point applied to procurement.

A specialist supplier may be more reliable than anything you could build. Often true. Keep the specialist when it delivers the better outcome, even if it is a shared dependency. What changes is the record: write down which risk you are accepting, and how its consequences will be contained if it fails.

Resilience lives in the paths that remain, not in the number of invoices.

Before you call it redundant

• Which component do both suppliers need? Name the storage, identity, network and control plane under each, down to the provider.
• Which recovery step needs the failed service? Check that the runbook, the credentials and the people can still act when the shared box is down.
• Which customer outcome can still be completed? Say what the degraded service is, and when it was last tested.
• What would a third supplier change? If it shares the same box, the answer may be almost nothing.
• Which shared risk is accepted, and who wrote it down? An accepted risk has an owner and a containment plan; a hidden one has neither.

Back to the two invoices on the desk. Leave them there; they are real contracts, and each buys something. But draw the line from each one down to the box they share, and rewrite the word in the margin. Not "independent," but independent of what: of the supplier's own outages, yes; of the identity service, no. Then decide whether the second answer is one you can live with, or one worth paying to change.