Single Point of Failure
One instance of a component that can take the whole system down — and how multi-node architecture removes it.
Interviewers rarely say “explain SPOF.” They ask you to design high availability, hit five nines (99.999%), avoid a single point of failure, or talk data resiliency. Same underlying idea: nothing important should exist only once.
What SPOF means
A single point of failure is a component you only have one of. If that node crashes, the whole system goes with it.
Picture a simple path: clients hit a load balancer, the load balancer sends work to an app server, the app talks to a database. Each of those is a node. One database. One app. One load balancer. Looks clean on a whiteboard — until the database dies and recovery might take hours or days depending on size and complexity.
Same story for the app layer: one microservice instance goes down and that capability is gone.
Client → load balancer → app → one database
A single point of failure is any component you only have one of — if it dies, the system dies with it.Multi-node
Multi-node means multiple instances of the same component. If one dies, something else is already running and can take the request.
Run more app instances behind the load balancer. Run more than one database node. And yes — the load balancer itself can be a SPOF, so you treat it the same way: more than one.
Physical failure counts too. One data center, one region, one building — fire, outage, or a bad day — and the whole deployment is gone. Teams run the same setup across multiple zones or data centers so one site can fail without taking the product offline.
Extra instances of app and DB — no single box owns the path
Multi-node means spare instances of the same component — and remember the load balancer and database need the same treatment.Having two database copies is not the end of the design. You still decide who accepts writes, who is read-only, and what happens when the primary site dies — one writer with standby replicas, or multiple live writers that must stay in sync. That choice is a separate tradeoff (active-passive vs active-active); for SPOF, the bar is simpler: nothing critical should exist only once.
When not to use this framing
Don’t multiply every box on day one. Start by naming the real SPOFs for this system. Two quiet read replicas behind a single writer that never fails is not the same problem as one production database with no backup path.
Also don’t confuse “we drew three app boxes” with high availability. If the database (or the load balancer) is still alone, you moved the SPOF — you didn’t remove it.
Production pitfall
Celebrating horizontal scale on the app tier while the data tier stays a singleton. Traffic fans out nicely until a schema migration, disk failure, or region blip takes the only database. Inventory SPOFs layer by layer — LB, app, cache, DB, queue — and ask what happens when that one dies.