Single Point of Failure (SPOF)

A single point of failure is any one component in a system whose failure causes the whole system (or a significant part of it) to go down. It's one of the simplest and most durable ideas in system design: if there's exactly one of something critical, that something is a ceiling on how available and reliable your system can ever be, no matter how well everything else is built.

The concept is deceptively simple, which is exactly why it's a favorite interview probe — an interviewer will often let you design a system for 20 minutes and then just ask, "what's the single point of failure here?" It's a fast way to check whether you're actually thinking about failure modes or just drawing boxes and arrows.

System Design Lab

Where SPOFs hide

Obvious SPOFs are easy to spot: one web server, one database. The harder ones to catch are the ones layered underneath a design that looks redundant on paper:

• A load balancer in front of ten redundant web servers is still a SPOF if there's only one load balancer — you've just moved the single point of failure one level up.
• A single database, even behind a fleet of stateless, horizontally-scaled app servers. This is the single most common SPOF in system design interview answers, because candidates spend all their design effort on the stateless layer and forget the stateful one.
• A shared configuration or service-discovery store (like a single instance of a config service or DNS record) that everything else depends on to even find its dependencies.
• A single region or data center. Redundant servers within one building don't help if a power outage, fire, or network cut takes out the whole building. This is the motivation for multi-region Disaster Recovery design.
• A single person or manual process — e.g., only one engineer knows how to run a critical migration, or a deploy requires someone to manually flip a switch. Organizational SPOFs are real SPOFs.

Removing a SPOF: the general pattern

Eliminating a SPOF almost always follows the same shape: replace "one" with "more than one," plus a mechanism to route around a failed one. Concretely:

1. Add redundancy — run N copies of the component instead of 1.
2. Add a way to detect failure — health checks, heartbeats (see Heartbeats).
3. Add a way to redirect around a failure automatically — this is Failover, often implemented via a load balancer or DNS-level switch.

Notice that step 1 alone isn't enough — two database replicas that both require a human to notice one died and manually promote the other is much better than one database, but it's not the same as an automated, highly available setup. The "single point of failure" for a two-node cluster with no automatic failover is arguably the on-call engineer's pager going off in time.

You can't remove every SPOF — so prioritize

In an interview, don't try to make every single box in your diagram redundant — that's both unrealistic and a signal you're pattern-matching rather than reasoning. Instead:

• Identify the SPOFs that exist in your design out loud.
• Rank them by how likely they are to fail and how bad the blast radius is if they do.
• Explain which ones you'd actually invest in fixing first, and why — and it's fine to say some are an acceptable risk given cost and probability. Real engineering teams make exactly this tradeoff constantly; a candidate who says "I'd accept this SPOF for now because X" often sounds more senior than one who tries to gold-plate every component.

Living with a SPOF: risks vs. fixes

Fixes

• ✓Add redundancy — run N copies instead of 1
• ✓Add failure detection — health checks and heartbeats
• ✓Add automatic failover so traffic reroutes without a human

Risks if left alone

• ✕A hard ceiling on availability, no matter how good the rest of the design is
• ✕Often hides one level up (a single load balancer in front of many servers)
• ✕Can be organizational, not just technical — one engineer who knows the migration script

Further Reading

• Wikipedia — Single point of failure — a concise definition with real-world examples across engineering disciplines.
• AWS Well-Architected Framework — Reliability Pillar — a section specifically on identifying and removing single points of failure in cloud architectures.