Single Point of Failure (SPOF)

What is it?

🔗 Think of it like a chain:

A chain is only as strong as its WEAKEST link. If one link breaks, the entire chain fails. A Single Point of Failure (SPOF) is that one weak link in your system — the ONE component that, if it goes down, takes EVERYTHING with it.

Imagine a city with only ONE bridge connecting two halves. If that bridge collapses, half the city is completely cut off. That bridge is a SPOF.

In tech: a SPOF is any component (server, database, network link, service) where failure causes the entire system to become unavailable. Good system design ELIMINATES single points of failure through redundancy.

💡 Simple Summary: SPOF = one component whose failure kills the entire system. Fix it by having backups (redundancy) for everything critical.

How it works — Like you're watching it happen

A system WITH SPOFs (bad):

Same system WITHOUT SPOFs (good):

❓ But wait — doesn't eliminating ALL SPOFs make the system really expensive?

Yes — there's a cost-reliability trade-off! Every redundant component costs money. A startup doesn't need 99.999% uptime (5 minutes downtime/year). A bank does. The goal is: identify SPOFs, assess their IMPACT, and add redundancy where the cost of downtime exceeds the cost of redundancy. Not everything needs to be redundant — just the critical path.

Why should you care? (Interview perspective)

Key Things to Remember

Real Examples You Use Daily

☁️ AWS Availability Zones — AWS has multiple data centers (AZs) per region. If you deploy in us-east-1a ONLY, a power outage there = you're down. Multi-AZ deployment means us-east-1a fails, us-east-1b takes over. No SPOF.

📺 Netflix Chaos Engineering — Netflix randomly kills servers, network links, even entire AZs in production. Their system is so redundant that users don't notice. This is how they achieve 99.99% uptime.

🏦 Banking systems — Banks have redundancy at EVERY layer: dual network links, replicated databases, backup data centers in different cities, diesel generators for power backup. A bank going down = losing millions per minute.

📱 WhatsApp — Uses multiple data centers globally. If one data center fails, DNS routes users to another. Messages are replicated across data centers. No single server failure can take WhatsApp down.

Common Mistakes in Interviews

❌ Not identifying SPOFs in your own design — You draw a design with one database and one app server. Interviewer asks "what are the SPOFs?" You should proactively identify them before being asked.

❌ Only thinking about servers — SPOFs can be: a software component (single Redis cache with no replica), a network link, a third-party dependency (if Stripe goes down, can you still accept orders?), or even a process (if CI/CD pipeline breaks, nobody can deploy).

❌ Adding redundancy without failover logic — Having 2 databases means nothing if there's no automatic failover. If the primary dies and you need a human to manually switch, you'll still have hours of downtime.

❌ Forgetting about "split-brain" — Two servers both think they're the primary. Both accept writes. Data diverges. This is WORSE than downtime. Discuss how failover prevents split-brain (quorum, fencing tokens).

❌ Not mentioning the cost trade-off — Adding redundancy everywhere is expensive. Show you can think about WHERE it matters most (critical path vs nice-to-have features).

🎯 Interview One-Liner

"I'd eliminate single points of failure by deploying across multiple availability zones with automated failover — redundant load balancers, database replicas with automatic promotion, and multi-region DNS — ensuring no single component failure causes system-wide downtime."

Interview Q&A