A SPOF’s failure alone stops a critical journey.
Recommendations die and the home page drops its carousel, not a SPOF. The payment provider dies and checkout stops, a SPOF for checkout.
“No SPOFs” means nothing until you name the failure.
Three app servers in one zone survive a host dying. Lose the zone, and the zone itself was the SPOF.
Every server has a twin. Done?
Bad: Twin every server
The SPOFs left hide in DNS, certificates, config, providers and people.
Good: Walk each journey
Ask of every dependency: if this vanishes, what does the user see?
You put two app servers behind a load balancer. No more SPOF?
Redundancy recurses
You moved the SPOF, not removed it. Every fix adds a box that needs its own fix.
1.5×
peak, enough to lose one of three zones
A spare helps only if survivors carry the load. Suppose checkout needs 8 servers: two zones need 16, three need 12.
The outage didn’t hit a box. It hit what every box shared.
Facebook’s DNS servers all withdrew their routes at once: running, but unreachable. One CrowdStrike update hit an estimated 8.5 million Windows devices.
Can’t remove it? Shrink it.
- Ten cells: one failing cell leaves 90% untouched
- Roll out changes, config too, zone by zone
- Data plane runs on last known state
- Degrade: turn hard dependencies into soft ones
Remember
A SPOF’s failure alone stops a critical journey; always name the scope. Remove it with copies across failure domains, or, if that costs more than the downtime, keep it and shrink its blast radius.