Single Point of Failure
Any component whose failure stops the whole system is a risk you've chosen, knowingly or not.
To an executive
One component, supplier or person that everything relies on is a risk the business has accepted, often without noticing. Finding these early prevents the memorable outages.
To an engineer
Hunt for hidden single points such as one certificate, DNS provider, account or expert. Redundancy above a shared dependency does not help, so check what the copies share.
The idea
A single point of failure (SPOF) is any element without redundancy whose failure brings the whole system down. Obvious ones, such as a single server, get fixed early. Hidden ones cause the memorable outages.
SPOFs are not only technical. A single DNS provider, a single TLS certificate, a single expert, a single payment vendor or a single cloud account can each be one. Redundancy above a shared dependency does not help: three regions that all rely on the same certificate are one point of failure, not three.
Why it works
A system is only as available as its least redundant critical part. You can run a service in three regions, but if all three depend on one database primary or one identity provider, that component sets your availability.
Naming SPOFs turns hidden risk into a decision. Once a SPOF is on the list, you can remove it, mitigate it or accept it with eyes open. Unlisted, it is a risk nobody chose.
Non-technical SPOFs are the easiest to miss. Diagrams show servers, not the one person who knows how renewal works or the contract that lapses on a fixed date.
Where it applies
- Design reviews, by walking each request path and each supporting process.
- Vendor selection, where a single provider for DNS, payments or identity becomes a dependency of everything.
- Operational processes, such as certificate renewal, key rotation and on-call knowledge.
- Multi-region and disaster recovery plans, to check that the regions are genuinely independent.
How to apply
- Map dependencies end to end, including control planes, DNS, certificates, secrets, licences, third-party APIs and people.
- Ask "what if this disappears?" for each item, and note what stops and for how long.
- Remove, mitigate or accept. Add redundancy where it is cheap, automate fragile manual steps, and record the SPOFs you deliberately keep.
- Check independence. Make sure redundant copies do not share power, network, accounts, deployment pipelines or configuration.
- Test failover. Redundancy that has never been exercised is a hope, not a control.
Example scenario
A multi-region application was designed so that any region could fail without customers noticing. It went down everywhere at once when its TLS certificate expired. Renewal had been a manual task for one engineer, who had left the company months earlier.
The team automated certificate renewal, added alerts thirty days before expiry, and ran a review of every other "one person knows how" process. They found two more: a manual DNS change during failover and a yearly licence renewal held by a single manager.
Questions to ask
- What is the one thing that, if it vanished tonight, would stop us?
- Which people, vendors, certificates or accounts are single points of failure?
- Is our redundancy truly independent, or does it share something underneath?
When not to use it
- Prototypes and internal tools where an outage is cheap and redundancy would slow learning.
- When removing the SPOF adds more risk than it removes, for example a complex active-active database setup that the team cannot operate confidently.
How it misleads you
Eliminating every SPOF regardless of cost, which can add complexity that causes outages of its own. Accept some deliberately, with eyes open and mitigations ready. The other trap is redundancy theatre: duplicate components that share one hidden dependency look safe on the diagram and fail together.
In the wild
Further reading
Last reviewed · Suggest an improvement