Skip to main content
Redundancy & Failoverlesson 1 of 4 · 2 min read

Single Points of Failure

Circle every box that appears once

A single point of failure is any component with no backup. When it dies, your system dies.

Draw your architecture and circle every box that appears exactly once. The lone database, the one balancer, the single application instance. Each circle is a bet that the thing never fails, and it is a bet you will lose.

The ones off the diagram

Look off the diagram for the sneaky ones, because that is where they live. Your DNS provider is one, as anyone who was on the wrong provider during the 2016 attack will tell you. The gateway all your outbound traffic funnels through is one.

So is the certificate that expires on a Saturday, and the shared cache four teams quietly depend on. So is the pipeline that is the only way to ship a fix, and the one engineer who knows the production database password. People and processes fail over worse than machines do.

Audit deliberately to find them. Walk every request path and every dependency and ask what happens if this exact thing disappears right now.

Follow the same discipline your cloud pushes you toward at the infrastructure layer. It is why the providers recommend spreading across at least three data centres. Losing one still leaves a majority of your capacity running.

Expect removing each one to cost you something. A second database means replication and failover logic. A second balancer means an address or a DNS record that can move between them.

The coordination machinery is itself new code that can fail. So prioritise by blast radius: fix the components whose death takes everything down before the ones that degrade a single feature.

Take three copies as your baseline for any stateful service in production. A primary plus two spares.

the shape of it
Load balancerone of themApp serverApp serverDatabaseone of them
step 1 of 2
Circle every box that appears once. Two here, and the app servers you duplicated were never the risk.

Worked example

Marta joins a 12-person startup as their first infrastructure hire and runs a SPOF audit in her second week. The findings doc lists nine items. The scary ones are not the servers: the whole product sits behind one HAProxy VM, the Postgres primary has a replica nobody has ever promoted, and DNS lives in a registrar account whose owner left the company in 2024. Three weeks later, before she has finished the fixes, the HAProxy VM's hypervisor dies at 2pm on a Tuesday and checkout is down for 43 minutes while someone rebuilds it from a snapshot. The postmortem quotes her audit line for line. The next quarter funds two load balancers behind a floating IP, a rehearsed Postgres promotion, and a company-owned registrar account.