Single Points of Failure

A single point of failure (SPOF) is any component that, if it fails, takes everything down with it. It's the Achilles' heel of system architecture—the one vulnerability that makes all your other reliability work meaningless.

Think about it: you can build the most elegant redundancy in the world, but if there's one component without a backup, that's where your system will break.

Why This Matters More Than You Think

You might have ten redundant application servers behind a load balancer with automatic failover. Beautiful. But if there's only one load balancer, all that redundancy is theater. When the load balancer fails, your ten servers become unreachable.

You might have database replication across three servers. Excellent. But if they all connect to one network switch, they all disappear together when that switch dies.

The pattern is always the same: elaborate redundancy undermined by a single overlooked dependency. SPOFs hide in the places you forgot to look.

Where SPOFs Hide

Infrastructure

Single power source: All servers on one electrical circuit means one tripped breaker brings down everything.

Single network path: All traffic through one router, switch, or connection means one failure disconnects everything downstream.

Single data center: One facility means power outages, cooling failures, or natural disasters become total outages.

Single cloud provider: Their outages become your outages. Multi-cloud is complex, but it eliminates this risk.

Single availability zone: Cloud providers design zones to fail independently. Running everything in one zone defeats this protection.

Application

Single database instance: The most common SPOF. When it fails, everything fails. Replication with automatic failover eliminates this.

Singleton services: Any service running as a single instance—authentication, payments, configuration—is a SPOF for everything that depends on it.

Single load balancer: Even with redundant backends, one load balancer means one failure point. Load balancers need HA pairs.

Single queue or message bus: If all services communicate through one queue server, that server's failure cascades everywhere.

Data

Single storage system: One disk, one storage array, one object store—any single storage location is a SPOF.

Single backup: If your only backup is corrupted or lost, you can't recover. Multiple backups in different locations.

Configuration in one place: Application config in a single file on a single server makes that file a SPOF.

People

Key person dependencies: If only one person knows how to deploy, recover, or fix critical issues, that person is a SPOF. Documentation and cross-training eliminate this.

Single communication channel: If all alerts go to one email or Slack channel that fails or gets missed, incidents go unnoticed.

Finding Your SPOFs

Map Every Dependency

Draw your system. Every component, every connection. For each component without redundancy, ask: "If this fails right now, what stops working?"

If the answer is "everything" or "critical functionality," you've found a SPOF.

Trace Critical Paths

Follow a user request through your system:

1. User connects to load balancer
2. Load balancer routes to application server
3. Application server queries database
4. Application server calls authentication service
5. Response returns

Any component in this path without redundancy is a SPOF for that user flow. Different flows have different critical paths—map the ones that matter most.

Learn From Incidents

Past outages reveal SPOFs. After every incident, ask: "Was this a SPOF? Would redundancy have kept us online?"

Eliminating SPOFs

Add Redundancy

The direct approach: duplicate the component, add failover.

• One database → replication with automatic promotion
• One load balancer → HA pair
• One network connection → secondary connection with automatic failover

Distribute Geographically

Some SPOFs exist at facility or regional level:

• Single data center → multiple availability zones or regions
• Single cloud region → multi-region architecture

Remove the Dependency

Sometimes the best solution is not needing the component at all:

• Must query a central service for every request? Cache the data locally.
• Must connect to a central database? Implement eventual consistency.
• Must call an external API synchronously? Process asynchronously so the API being down doesn't block users.

Degrade Gracefully

If you can't eliminate a SPOF, design the system to survive its failure:

• Recommendation engine fails → show recent items instead
• Search service fails → fall back to simpler filtering
• Payment provider down → queue transactions for later

This doesn't eliminate the SPOF but reduces impact from "complete failure" to "degraded functionality."

The Cost of Eliminating SPOFs

Eliminating every SPOF is expensive:

• Infrastructure costs: Redundant components mean double the resources
• Operational complexity: More components, more monitoring, more procedures
• Development time: Failover mechanisms, health checks, testing
• Consistency challenges: Redundant stateful components must stay synchronized

Not every SPOF needs elimination. Prioritize based on:

• Criticality: Core features deserve more redundancy than nice-to-have features
• Impact: Complete outage or degraded experience?
• Probability: Frequent failures deserve redundancy even with moderate impact
• Recovery time: 5-minute manual recovery might be acceptable; 8-hour recovery isn't

Acceptable SPOFs

Some SPOFs are pragmatically acceptable:

• Low-criticality services that enhance but aren't essential
• Components so reliable that redundancy costs more than expected failure impact
• Situations where manual recovery takes minutes and failures are rare

The key is making conscious decisions. Acceptable SPOFs should be explicitly documented, closely monitored, and revisited as the system grows.

Hidden SPOFs

The subtle ones are the dangerous ones:

Shared underlying infrastructure: Redundant virtual machines on separate hosts—but those hosts share one storage array. The array is a hidden SPOF.

Common dependencies: Redundant application servers that all depend on the same authentication service.

Correlated failures: Redundant components running identical software can all fail from the same bug. True redundancy sometimes requires diversity—different software, different vendors.

Human SPOFs: The on-call engineer who's the only one who knows critical procedures.

Shared credentials: All services using one API key fail simultaneously when that key is revoked.

Continuous Vigilance

Systems evolve. Components that had redundancy lose it through architecture changes. New features introduce new SPOFs.

Build SPOF analysis into:

• Architecture reviews: Evaluate new features before implementation
• Incident post-mortems: Identify SPOFs that contributed
• Regular audits: Periodically map dependencies
• Chaos engineering: Deliberately fail components to verify redundancy actually works

The goal isn't perfection—it's understanding your SPOFs, making conscious decisions about which to address, and systematically improving over time.