Scalability
Fault Tolerance
The system keeps working correctly despite component failures — achieved through redundancy, replication, graceful degradation and no single points of failure. The mindset is to assume everything fails eventually and design to survive it. It is proven, not hoped for: chaos engineering deliberately injects failures to test resilience.
Purpose
Fault tolerance is the property that a system keeps working — perhaps degraded, but working — when components fail. The mindset shift is treating failure as normal input, not exception: disks die, networks partition, dependencies time out, and the design question is 'then what?' for each.
When to Use It
Redundant instances surviving a node loss; a replica promotion surviving a database failure; a feature falling back to defaults when its dependency is down (recommendations unavailable → show bestsellers, not an error page). Anywhere an SLA outlives any single component's reliability.
Trade-offs
Redundancy costs money and coordination complexity — and recovery machinery (failover, retries) misfiring has caused its own famous outages. The discipline is matching tolerance to actual failure modes and testing it: chaos engineering deliberately kills components in production-like conditions precisely because untested resilience is imaginary.
Implementation
Eliminate single points of failure layer by layer; contain failures with bulkheads and circuit breakers so one bad dependency cannot cascade; degrade gracefully with explicit fallbacks; make recovery automatic (health checks, restarts, failover). Then verify: fault-injection tests and game days turn hope into evidence.