Single Point of Failure (SPOF)
You draw your architecture on the whiteboard and the interviewer points at one box and asks 'what happens when this dies?' Finding and eliminating single points of failure is a core design skill.
The Concept Explained
A single point of failure is any component whose loss takes down the system. The definition is simple. Finding them is not, because the dangerous ones are rarely drawn on the diagram.
Engineers get good at spotting the obvious ones quickly. One web server, one database, one cache. Those get redundancy early because they are visible. What survives into production is the category of SPOF that never appears as a box: the DNS zone every client resolves through, the certificate authority whose expiry stops all mTLS at once, the secrets manager every pod calls on startup, the CI pipeline that is the only path to deploying a fix, the one engineer who understands the failover procedure.
The test that finds them is mechanical, and it is worth applying to every element of a design rather than only the ones that look important: point at it and ask what happens when it stops. Not "if" it stops. Everything stops eventually, and a component's importance has no bearing on its failure rate.
A component is a SPOF if there is exactly one of it in the request path, or if there are several but they share a fate. Two database replicas in the same rack are one failure domain wearing two hostnames. Redundancy only counts when the copies can fail independently.
That second clause is where most real architectures fall down. Redundancy is easy to add and independence is hard to verify, so systems accumulate components that look redundant on a diagram and fail together in practice.
How It Works
Work through a standard three-tier architecture, because this is the exact prompt interviewers use. Client, DNS, load balancer, web tier, application tier, database, and the supporting services around them.
Every SPOF in a Standard Three-Tier Architecture
Usually the first thing every client touches and the most commonly missed SPOF. A single zone, a single provider, or a single registrar account. Fix: multiple authoritative nameservers across two independent DNS providers, and sensible TTLs so a change can actually propagate during an incident.
Making the web tier redundant while routing all of it through one balancer moves the SPOF rather than removing it. Fix: redundant balancers across availability zones, fronted by DNS or anycast so the failure of one is routed around without manual work.
The easy layer. Stateless instances behind health checks, spread across zones, with enough headroom that losing a zone does not overload the survivors. This is the only tier where naive redundancy actually works.
The hard one, because writes cannot simply be copied. One primary accepting writes is a SPOF by construction. Fix: a standby with automatic promotion, quorum-based election to avoid two primaries, and honesty about the data loss window if replication is asynchronous.
Secrets manager, config store, service registry, certificate authority, object storage for user uploads. Each is a dependency on the startup or request path that rarely appears on the diagram, and each takes the whole system down when it fails.
If CI is the only way to ship a fix and CI is down during the incident, you cannot recover. A break-glass deploy path that does not depend on the normal pipeline is a real availability control, not a nicety.
Hover to expand each layer
The Two Failure Modes That Defeat Redundancy
Shared fate. Two instances in one rack, two zones in one region, two replicas on one storage array, two services behind one NAT gateway. The copies exist but they die together. Eliminating a SPOF means placing the copies in different failure domains, which is why availability zones exist and why "multi-AZ" is a meaningful phrase while "two instances" is not.
Correlated logic. Both replicas run the same code, so both crash on the same malformed input. Both use the same certificate, so both fail at the same second when it expires. Both call the same downstream, so both stall when it does. This is the failure mode that surprises people most, because it is invisible in any diagram that shows only topology.
The most reliable way to take down a fully redundant system is a change applied to every replica at once. Configuration pushes, certificate rotations, and simultaneous deployments all bypass redundancy entirely, because redundancy protects against a component failing, not against every component being given the same bad instruction.
The Failover Path Is Itself a SPOF
A standby that has never been promoted is an assumption. The mechanism that detects failure, elects a new primary, and redirects traffic is code, and code that only runs during incidents is code that is only tested during incidents.
This is why regular failover exercises count as availability engineering rather than housekeeping. A failover path that has been exercised this month is a control. One that has not been exercised in a year is a plan.
System Design Implications
When an interviewer points at a box, they want a structured answer rather than "add another one." The structure that works:
Name the failure. What exactly breaks when this dies, and what does the user see? "The database primary fails, so all writes reject while reads continue from replicas" is a much stronger answer than "the system goes down."
Name the detection. How does the system know? Health checks, heartbeat timeout, quorum loss. Time to detect is part of the outage, and candidates almost always skip it.
Name the recovery. Automatic or manual, how long, and what is lost. If replication is asynchronous, promotion loses whatever had not shipped, and being explicit about that window is a mark of seniority.
Name the new risk. Every SPOF you remove creates something. Two database primaries risk split brain. Two DNS providers risk configuration drift between them. Automatic failover risks flapping under load. Interviewers are listening for whether you know that redundancy is a trade rather than a free win.
When Leaving a SPOF Is Correct
Not every SPOF should be eliminated, and saying so with justification is a stronger signal than reflexively making everything redundant.
Leave it when the cost of removal exceeds the cost of the outage it prevents: an internal admin tool that ten people use does not need multi-region failover. Leave it when removing it introduces a correctness risk worse than the availability risk, which is the standard argument for keeping a single writer rather than accepting divergence. Leave it when the redundancy would be theatrical, sharing fate with the original and buying nothing but cost and false confidence.
What is not acceptable is leaving one by accident. The distinction an interviewer is testing is whether you identified it and made a decision, or simply did not see it.
Tradeoffs and Decision Framework
| SPOF | Standard fix | New risk it introduces |
|---|---|---|
| DNS | Two providers, multiple nameservers | Config drift between providers |
| Load balancer | Redundant LBs, anycast or DNS failover | Slower failover than a health check |
| Web or app tier | Stateless instances across zones | Needs headroom to absorb a zone loss |
| Database primary | Standby with automatic promotion | Split brain, data loss on async replication |
| Cache | Clustered, replicated, or sharded | Thundering herd when a node is lost |
| Secrets or config store | Local cache with a stale-serve policy | Serving stale credentials or config |
| Deploy pipeline | Break-glass manual path | A route that bypasses normal review |
| Operator knowledge | Runbooks, exercised failovers | Real time cost, ongoing maintenance |
The framework: enumerate every component on the request path plus every component on the startup path, which is the one people forget. For each, ask what breaks, how it is detected, how it recovers, and what the recovery introduces. Then rank by blast radius multiplied by likelihood, and fix in that order rather than in the order things appear on the diagram.
Trace a single request end to end and say every dependency out loud, including the ones that are not services: DNS resolution, TLS certificate validation, service discovery lookup, secrets fetch at startup, and the network path itself. The SPOFs an interviewer is waiting for are almost always in that list rather than in the boxes you drew.
Common Mistakes
Only looking at boxes on the diagram. DNS, certificates, secrets stores, and deploy pipelines take systems down regularly and are drawn approximately never.
Counting copies instead of failure domains. Three instances in one rack is one failure domain. The count is not the property that matters.
Forgetting the startup path. A service that survives the loss of its config store while running but cannot start without it has a SPOF that only appears during recovery, which is exactly when you need to restart.
Assuming failover works. An untested promotion path is a hypothesis, and incidents are a bad time to test hypotheses.
Ignoring correlated logic failure. Identical replicas fail identically on identical input. Topology redundancy does nothing against a poison message or an expiring certificate.
Adding redundancy without capacity headroom. Two zones each running at 60% means losing one leaves the survivor at 120%, which is an outage with extra steps.
Not naming the new risk. Every SPOF removed adds something, most often split brain. Interviewers listen specifically for this.
Look at a typical three-tier architecture. Identify every single point of failure and explain how you'd eliminate each one.