Theory
Single Point of Failure (SPOF)
📋 Overview
A Single Point of Failure (SPOF) is any component of a system which, if it fails, causes the entire system to stop functioning. Identifying and eliminating SPOFs is the primary goal of high-availability (HA) and fault-tolerant system design.
🏗️ Core Principles & Characteristics
- Dependency Chains: SPOFs often hide in deep dependency chains (e.g., a critical third-party API that your entire login flow depends on).
- Hard vs. Soft SPOFs:
- Hard SPOF: Total system blackout (e.g., your primary database goes down).
- Soft SPOF: Degraded performance or loss of specific features (e.g., your recommendation engine fails, but users can still browse).
- The "No SPOF" Paradox: In reality, you can never eliminate every SPOF; you can only push them to layers where they are highly unlikely to fail (e.g., the global internet or the cloud provider's backbone).
⚖️ Trade-offs: Pros & Cons
Pros of Eliminating SPOFs
- Business Continuity: Revenue and reputation are protected against hardware and software failures.
- Maintenance Flexibility: Redundancy allows for "rolling upgrades" where components are taken offline for maintenance without affecting users.
- Peace of Mind: Engineering teams can rely on automated failover rather than manual 3 AM emergency calls.
Cons of Eliminating SPOFs
- Increased Cost: Redundancy usually means doubling or tripling your infrastructure spend.
- System Complexity: Managing data consistency across redundant nodes (e.g., master-slave replication lag) adds significant engineering overhead.
- Split-Brain Risk: In a redundant system, if nodes lose communication with each other, they might both think they are the "leader," leading to data corruption.
🌍 Real-World Implementation
- Multi-AZ/Multi-Region: Deploying applications across different AWS Availability Zones or Regions to protect against data center or regional outages.
- Load Balancers: Using a cluster of load balancers (with VRRP/Keepalived) to ensure the entry point itself isn't a SPOF.
- RAID Storage: Redundant Array of Independent Disks to protect against individual hard drive failures.
💡 Interview "Gotchas" & Tips
- Human SPOFs: Don't forget that a single person (e.g., "The guy who knows how the legacy code works") is a SPOF. Mention documentation and cross-training as mitigations.
- Shared Fate: Be careful of "hidden" SPOFs where two "redundant" servers are actually on the same physical rack or use the same top-of-rack switch.
- DNS as a SPOF: Many candidates forget that if your DNS provider goes down, your multi-region setup is unreachable.
📐 Suggested Architecture Primitives
- Redundancy (N+1): Having at least one more component than is strictly necessary for the load.
- Heartbeats & Health Checks: For automated detection of component failure.
- Circuit Breakers: (e.g., Hystrix/Resilience4j) To prevent a failing component from dragging down the rest of the system.
- Stateless Services: To make it trivial to spin up new instances and replace failing ones.
Canvas