Single Points of Failure¶

Prerequisites: Reliability Overview

← Reliability | Next: Circuit Breakers →

Why This Exists¶

Every outage retrospective eventually reaches the same sentence: "and there was only one of it." One database with no replica. One load balancer with no standby. One person who knew how to restart the payment service. A single point of failure (SPOF) isn't a bug — it's a design decision, usually made implicitly by never asking "what happens when this dies," and it's the cheapest thing in this whole curriculum to find if you actually look for it before an incident does.

The skill being tested — in an interview and in a real architecture review — is not "do you know what SPOF means." It's: given this diagram, can you point at the one box whose failure takes the whole system down, before anyone else in the room does?

What Makes Something a SPOF¶

A SPOF is any component or system whose failure stops the entire (or a critical) function — not because it's important, but because there is no backup path around it.

flowchart LR
    subgraph SPOF["System with a SPOF"]
        U1["Users"] --> LB1["Load Balancer<br/>(only one)"]
        LB1 --> WS1["Web Server<br/>(only one)"]
        WS1 --> DB1[("Database<br/>(only one)")]
    end
    style LB1 fill:#b71c1c,color:#fff
    style WS1 fill:#b71c1c,color:#fff
    style DB1 fill:#b71c1c,color:#fff

flowchart LR
    subgraph HA["System without a SPOF"]
        U2["Users"] --> LB2{{"Load Balancer<br/>(redundant pair)"}}
        LB2 --> WS2["Web Server 1"]
        LB2 --> WS3["Web Server 2"]
        WS2 --> DBP[("Database<br/>Primary")]
        WS3 --> DBP
        DBP -.replication.-> DBR[("Database<br/>Replica")]
    end

In the left diagram, every box is red because every box only has one instance — the load balancer, the web server, and the database are each a SPOF in their own right, and the system's actual availability is the product of all three, not the availability of the weakest one alone. In the right diagram, redundancy at each tier means one failure at any tier still leaves a healthy path from user to data.

Where SPOFs Actually Hide¶

The obvious ones (one server, one database) get caught in any review. The ones that cause real incidents are usually less obvious:

This is why a SPOF audit has to walk the actual dependency graph, not the boxes on the architecture slide — the network switch and the deploy credential are both real dependencies of "can we serve traffic," even though neither is an application component.

Common SPOFs in a Typical Application¶

• Single application server (no horizontal scaling)
• Single database instance, no replica
• Single network device (switch, router, firewall) everything routes through
• Single power supply / single rack
• Single storage volume (disk failure = data loss, not just downtime)
• Single DNS server or record with no failover
• Single code repository or CI/CD server with no backup
• Single admin or person holding critical access nobody else has

Notice that only about half of this list is a "server" in any normal sense — the rest is infrastructure, process, and people, which is exactly why a SPOF audit run purely against an application architecture diagram misses half the real risk.

The Five Levers That Remove or Manage a SPOF¶

None of these are new concepts on this site — SPOF elimination is really "apply the pattern you already know, to the box you haven't gotten around to yet." The first four actually remove the SPOF's availability impact — the system keeps serving traffic through the failure. The last one, monitoring, does not: it detects the failure faster so a human or automation can respond, but a monitored SPOF is still a SPOF until something on the "remove" side of this table also exists.

Regular backups belong on this list too, but answer a different question than the other five: redundancy and failover keep the system available through a failure; backups are what saves you when the failure is data corruption or deletion, which replicates just as faithfully as good data does. A replica of corrupted data is still corrupted data — this is why backups (point-in-time, ideally with a delay or immutability window) are not optional even in a fully redundant, fully replicated system.

Redundancy Isn't Free — Name the Cost¶

Removing a SPOF is a trade-off, not a strict improvement, and an interviewer will probe whether you know what you paid:

Interview Questions¶

Key Takeaways¶

Previous: Reliability | Next: Circuit Breakers