Skip to content
←System Design

// System Design · 08

Single Point of Failure

One componentleads toWhole system depends on it

The one piece that, if it dies, takes everything with it.

How it fits together

Single Point of Failure structure«client»ClientLoad balancer2 nodes, 2 zonesAPI (zone a)API (zone b)Primary DBone instanceno standby1 request2 query
uses / calls· numbered steps replay in order
  • Client uses / calls Load balancer (1 request)
  • Load balancer uses / calls API (zone a)
  • Load balancer uses / calls API (zone b)
  • API (zone a) uses / calls Primary DB (2 query)
  • API (zone b) uses / calls Primary DB

Spot it

  • "We can't restart that box"
  • One cron host, one Redis, one DNS provider
  • Only one person knows how it works

It costs

Removing a SPOF usually means paying for idle capacity and coordination.

Go deeperThe full explanation and what to ask for · 1 min readExpand

Look beyond servers: a single load balancer, certificate, secret, region, deploy pipeline or person can each be one.

You cannot remove every SPOF. Rank them by likelihood times blast radius, and fix from the top.

Ask for it

  • SPOF
  • blast radius
  • failover
  • multi-AZ
  • dependency map

Map every dependency of this request path and mark which ones are single points of failure. For each, propose the cheapest way to remove it or shrink its blast radius.

Connects to