What Is a Single Point of Failure?
A single point of failure (SPOF) is any component in your stack whose failure causes a complete service outage. One database server, one load balancer, one DNS provider — any of these can be the thing that makes your 3 a.m. phone ring.
The goal isn't zero risk. It's ensuring no single thing can take everything down.
Step 1: Draw Your Dependency Map
Before you fix anything, you need to see everything. Map every layer of your stack:
- DNS resolution
- TLS termination / CDN
- Load balancers
- Application servers
- Databases and caches
- Object storage / file systems
- Third-party APIs your app requires at request time
- Your monitoring and alerting system itself
For each component, ask: if this fails right now, does the site go down? If the answer is yes, you've found a SPOF.
Step 2: Fix the Common Offenders
DNS
DNS is the most overlooked SPOF. If you're using a single DNS provider and they have an outage, no amount of redundant servers behind them matters.
- Use a DNS provider that operates multiple anycast PoPs.
- Consider secondary DNS: configure a second provider as a secondary nameserver and set a low-ish TTL (300–900 seconds) so clients aren't stuck.
- Avoid setting your TTL to zero — it kills caching and makes every lookup a live query.
Load Balancers
A single load balancer is a SPOF. Options:
- Cloud-managed load balancers (AWS ALB, GCP Load Balancing) are inherently redundant within a region — use them.
- Self-managed HAProxy or Nginx: run two instances and use a floating IP via keepalived/VRRP so failover is automatic.
- Cross-region active-active or active-passive setups require routing logic at the DNS or anycast layer.
Application Tier
This one is usually already handled — most teams run more than one app server. But check:
- Are all instances in the same availability zone? A single AZ outage would wipe them all out.
- Does your deployment process briefly leave zero healthy instances?
- Are health checks actually testing app logic, not just TCP connectivity?
Databases
Databases are the hardest layer to make redundant because of state.
- Postgres: use streaming replication with a standby and a tool like Patroni or repmgr for automatic failover. Managed options like RDS Multi-AZ or Cloud SQL handle this for you.
- MySQL/MariaDB: similar story — Group Replication or a managed multi-AZ offering.
- Avoid synchronous replication across regions unless you've measured and accepted the latency cost — the round-trip penalty on writes can be severe.
- Test your failover. Scheduled, deliberately, before an incident forces you to.
Caches (Redis, Memcached)
If your app falls over when Redis is unavailable, that's a SPOF. Make your application degrade gracefully — go to the database, serve stale data, or return a simplified response — rather than returning 500s.
For Redis specifically, Redis Sentinel provides automatic failover. Redis Cluster shards data across nodes and is self-healing.
Third-Party Dependencies
Payment processors, auth providers, enrichment APIs — these are SPOFs you don't control. Tactics:
- Circuit breakers: stop hammering a failing dependency and return a fallback fast.
- Timeouts: never let a slow third-party API hold a request thread open indefinitely.
- Feature flags: be able to disable non-critical integrations instantly.
Step 3: Monitor From Outside Your Infrastructure
Here's the irony of internal monitoring: if your monitoring stack lives in the same region as your application, an infrastructure event can take both down simultaneously. You won't get an alert. You'll find out from a customer.
External uptime monitoring — checks running from multiple geographic regions against your public endpoints — gives you a signal that's independent of your internal state. When a check from Tokyo and Frankfurt both fail while your US checks pass, that's actionable information about a regional routing problem, not a false alarm.
This is where a service like Pingy earns its keep: multi-region checks tell you where the failure is visible, which narrows your diagnosis before you've even opened a terminal.
SPOF Audit Checklist
- DNS has secondary provider or anycast with multiple PoPs
- Load balancers are redundant and not confined to a single AZ
- App servers span at least two availability zones
- Database has a tested automatic failover mechanism
- Cache failures degrade gracefully instead of causing errors
- Third-party API calls have timeouts and circuit breakers
- Monitoring runs from outside your infrastructure
- Deployment process keeps at least one healthy instance running
Key Takeaways
- Map your stack before you fix it — you can't eliminate a SPOF you haven't identified.
- Redundancy only helps if failover is automatic and tested; untested failover is theater.
- State (databases, sessions) is the hardest layer — prioritize it.
- External, multi-region monitoring is itself part of a resilient architecture.
- Degrading gracefully under partial failure is often more valuable than full redundancy of every component.