Identifying the Weakest Link
A Single Point of Failure (SPOF) is any component in your system that, if it fails, causes the entire system to stop functioning — regardless of how redundant everything else is. A chain is only as strong as its weakest link. A system is only as available as its most fragile component.
Common SPOFs by Category:
- Infrastructure: A single load balancer with no standby. A single availability zone. A single network switch connecting your data center to the internet.
- Database: A primary (master) database with no read replicas or standby instance. If the primary fails and there's no replica to promote, writes stop entirely.
- External Dependencies: Relying on a single third-party API with no fallback. If Stripe goes down and you have no secondary payment processor, you cannot take orders. If your single SMS provider fails, users can't receive two-factor authentication codes.
- Human: "Only Dave knows how to deploy this." This is a SPOF in your team, not your infrastructure. It's just as dangerous. Bus factor — the number of people who would need to be hit by a bus before a system becomes unmaintainable — should always be greater than one for critical systems.
Strategies to Eliminate SPOFs:
- Redundancy (Active-Passive): Have a hot standby that takes over automatically when the primary fails. The standby is idle during normal operation. Recovery time is seconds to minutes.
- Redundancy (Active-Active): Multiple instances all serving traffic simultaneously. If one fails, the others absorb its load. Recovery time is near-zero, but you must handle the complexity of distributed state.
- Graceful Degradation: Design the system to continue functioning at reduced capacity when a component fails. If the "Recommendations" service goes down, show the homepage without recommendations — don't show a 500 error. If the search service fails, show a "Search temporarily unavailable" message rather than crashing the entire page.
- Circuit Breakers: When a downstream service starts failing, stop sending it requests immediately rather than letting failures cascade. After a timeout, send a small probe request to check if the service has recovered. This prevents one failing service from taking down everything that depends on it.
The most insidious SPOFs are the ones that only appear under load. A database that handles normal traffic fine might become a SPOF at 10x traffic because connection pool exhaustion turns it into a bottleneck that blocks all application servers simultaneously.