Single points of failure (SPOF)

Why it matters

Most outages have a boring shape: one thing that everything depended on stopped working. The database with no replica. The load balancer that was itself a single machine. The expired TLS certificate. The engineer who knew the password. Finding single points of failure is the cheapest reliability work there is, because the fix is almost always "have two", and the cost of missing one is the whole system.

The idea

A single point of failure is a component whose failure causes the system to fail, because nothing can take over its role. On a diagram it is any box with no sibling, any arrow that has nowhere else to go.

Where they hide

The obvious ones are infrastructure: a lone database, a lone load balancer, a lone message broker, one availability zone. The ones that cause real outages are quieter:

• Shared dependencies: every service calls the same auth service, config store or feature-flag endpoint. Redundant services with one shared SPOF are not redundant.
• Control plane: DNS, certificates, the secrets manager, the deploy pipeline. These rarely fail, so nobody rehearses the day they do.
• Capacity: two servers each running at 80 percent are a SPOF in disguise; lose one and the other falls over from the load.
• Data: one region holding the only copy, or backups that have never been restored.
• People and process: a single on-call engineer, a runbook in one person's head, a vendor account owned by someone who left.

The remedies

SPOF	Standard remedy	What to watch
Single database	Replica with automatic failover; backups restored on a schedule	Replication lag, failover time, split brain
Single load balancer	Managed, multi-instance balancer or active-passive pair with health checks	The health check itself; DNS pointing at it
Single zone or region	Multi-zone by default; multi-region for the paths that justify it	Data consistency across regions, cost
Shared service	Make it redundant and make callers degrade without it	Timeouts, cached last-known-good values
Certificates, DNS, secrets	Auto-renewal, two providers, alerts weeks before expiry	Who gets paged
Capacity at 80 percent	Size for n-plus-one: lose one node and still have headroom	Autoscaling lag
One person	Runbooks, rotation, shared ownership of accounts	Bus factor during holidays

Blast radius

Not every SPOF deserves fixing. Ask what its failure takes down and for how long. A SPOF whose blast radius is one optional widget, with a five-minute recovery, is a note in a doc. A SPOF under checkout is the first item on the list of things to fix this quarter.

Trade-offs

Redundancy costs money and adds the coordination problems of running two of something: which one is primary, how they agree, what happens when both think they are in charge. Sometimes a well-monitored single component with a fast rebuild path is the right answer, as long as the choice is deliberate and its blast radius is understood. The failure is not having a SPOF; it is not knowing you have one.

In an interview

After drawing the high-level design, walk the diagram and name the single points of failure before the interviewer does: "The balancer and the database are singles here. The balancer I would make a managed multi-instance one; the database gets a replica with automated failover, and I would call out that failover takes about thirty seconds, during which writes fail." Then name a hidden one, such as DNS or the shared auth service. That second step is what distinguishes experience from textbook knowledge.