System Design: Reliability and Fault Tolerance
Master high availability, redundancy models, automated failover, disaster recovery (RPO/RTO), chaos engineering, graceful degradation, API idempotency, and SLA/SLO error budgets.
1. High Availability Concepts & Core Reliability Metrics
High Availability (HA) ensures a system remains operational and accessible with minimal unplanned downtime. Availability is quantified as a percentage of uptime ("nines") and measured using the relationship between failure frequency and recovery speed.
High Availability 'Nines' & Incident Lifecycle Metrics (MTBF, MTTD, MTTR)
System DesignCalculating annual downtime thresholds and tracing automated detection and self-healing recovery phases
Availability Formula & The 'Nines'
Availability = MTBF / (MTBF + MTTR). Each additional 'nine' increases engineering complexity and cost exponentially.
- 99.0% (Two 9s): ~3.65 days downtime/year (Basic web app)
- 99.9% (Three 9s): ~8.76 hours downtime/year (Standard cloud SLA)
- 99.99% (Four 9s): ~52.6 minutes downtime/year (High-scale enterprise)
- 99.999% (Five 9s): ~5.26 minutes downtime/year (Telecom / Critical infrastructure)
Core Incident Time Metrics
Key Site Reliability Engineering (SRE) indicators measuring incident response speed.
- MTBF (Mean Time Between Failures): Average uptime duration between system faults
- MTTD (Mean Time To Detect): Average time elapsed from incident start to alert firing
- MTTR (Mean Time To Repair/Recover): Average time taken to restore full service functionality
2. Redundancy Models & Eliminating Single Points of Failure (SPOF)
Reliability requires eliminating Single Points of Failure (SPOF) by duplicating critical components across compute, storage, and networking layers.
Active-Active vs Active-Passive Redundancy Architecture Topologies
System DesignComparing continuous load sharing against hot/warm standby failover models
Active-Active Redundancy
All redundant nodes concurrently process live client requests via load balancers. If any node fails, healthy nodes instantly absorb the traffic.
- Near-zero failover downtime
- Optimal hardware resource utilization
- Requires multi-master replication and conflict resolution
Active-Passive (Standby) Redundancy
Primary node handles 100% of traffic while standby node remains idle, synchronizing state via continuous replication logs.
- Simpler consistency model (Single writer)
- Standby hardware sits idle during normal operation
- Requires heartbeat probing and promotion failover delay
3. Automated Failover Strategies & Split-Brain Prevention
When primary systems crash, automated failover mechanisms promote replicas without human intervention. However, temporary network partitions can cause a catastrophic Split-Brain scenario where two nodes both believe they are the active master.
Automated Failover Sequence & Quorum-Based Fencing (STONITH)
System DesignVisualizing heartbeat timeouts, majority quorum voting (Raft/Consul), and Virtual IP remapping
Split-Brain Hazards & Defense Mechanisms
If a network partition isolates Node A and Node B, both nodes might accept concurrent writes, causing permanent data divergence and corruption.
- Quorum Consensus: Require (N/2) + 1 nodes (e.g. 2 out of 3) to vote before promoting a new leader
- Fencing Tokens: Monotonically increasing epoch numbers; storage rejects writes from older epoch tokens
- STONITH ("Shoot The Other Node In The Head"): Power off or disconnect unresponsive nodes via IPMI hardware switches before promoting standbys
4. Disaster Recovery (DR) Strategies (RPO vs RTO)
Disaster Recovery (DR) plans for catastrophic regional outages (earthquakes, data center power loss, cloud region failures). Strategies are governed by two business constraints: RPO and RTO.
Cloud Disaster Recovery Strategy Spectrum (Cost vs Recovery Speed)
System DesignComparing Backup & Restore, Pilot Light, Warm Standby, and Multi-Region Active-Active
RPO vs RTO Constraints
Defining the maximum acceptable loss thresholds.
- RPO (Recovery Point Objective): Max acceptable data loss measured in time (e.g. 5 minutes of lost transactions)
- RTO (Recovery Time Objective): Max acceptable system downtime before restoration (e.g. 15 minutes of outage)
The 4 DR Architectural Patterns
Balancing recovery velocity against infrastructure cost.
- Backup & Restore: Regular S3 snapshots; slow recovery (Hours/Days, $)
- Pilot Light: Core DB continuously replicated; compute spun up on demand (Minutes, $$)
- Warm Standby: Scaled-down replica always running in secondary region (Seconds/Minutes, $$$)
- Multi-Site Active-Active: Full traffic served across multiple global regions simultaneously (RPO=0, RTO=0, $$$$)
5. Chaos Engineering & Proactive Resilience Testing
Chaos Engineering is the discipline of experimenting on a system in production to build confidence in its capability to withstand turbulent conditions. Pioneered by Netflix with the Simian Army.
Chaos Engineering Continuous Resilience Feedback Loop
System DesignHypothesis formulation, canary blast radius containment, fault injection, and architectural hardening
Principles of Chaos Engineering
Chaos experiments reveal hidden bottlenecks before real production outages strike.
- Chaos Monkey: Randomly terminates production container pods / EC2 instances during business hours
- Chaos Gorilla: Simulates total Availability Zone (AZ) failure to verify auto-rebalancing
- Chaos Kong: Simulates entire AWS Region outage to validate global DNS failover
- Blast Radius Containment: Always start experiments on a tiny % of canary traffic before scaling up
6. Graceful Degradation & Load Shedding
When under extreme load or partial infrastructure failure, resilient systems avoid catastrophic total outages by shedding low-priority workloads and falling back to degraded, simplified functionality.
Graceful Degradation & Load Shedding Decision Pipeline
System DesignPrioritizing critical transaction checkout flows while dropping non-essential background workloads
Graceful Degradation Patterns
Isolating failures in non-critical components.
- Fallback Caching: Serve stale cache data if backend databases are overwhelmed
- Feature Flags / Kill Switches: Remotely toggle off expensive UI features (e.g. "Related Items")
- Static Fallback UI: Display informative placeholders instead of raw 500 error pages
Load Shedding Mechanics
Dropping requests early at the API Gateway.
- CPU / Memory Thresholds: Shed non-essential traffic when CPU exceeds 85%
- Priority Queues: Process Payment & Auth requests; reject Search & Analytics with HTTP 503 / 429
- LIFO Queueing: Under extreme queues, drop oldest requests first since client has likely timed out
7. Idempotency in APIs & Distributed Transactions
An API operation is idempotent if making multiple identical requests has the exact same side effect on server state as making a single request (f(f(x)) = f(x)). This is vital to prevent double charges during network retries.
Idempotency Key Lifecycle & Atomic Distributed State Locking
System DesignTracing SETNX mutex locks, in-progress conflict resolution, and cached response replaying
HTTP Methods & Idempotency Rules
Standards defined by RFC 7231.
- GET, HEAD, OPTIONS: Safe and Idempotent (Read-only, no state mutation)
- PUT: Idempotent (Replaces entire resource; repeated calls produce identical state)
- DELETE: Idempotent (Deleting resource X multiple times results in X being gone)
- POST / PATCH: Non-Idempotent by default; requires client-generated Idempotency-Key headers (UUIDv4) for safe retries
Production-Grade API Idempotency Middleware with Redis Atomic Locking
Middleware that uses atomic Redis locks to safely deduplicate retried API requests.
Press Run to execute the code and see output here.
8. Timeouts, Retries, Exponential Backoff, Jitter & Circuit Breakers
Uncontrolled retries without backoff create Retry Storms (Thundering Herds) that amplify small blips into catastrophic cascading outages. Resilient architectures combine strict timeouts with Exponential Backoff, Full Jitter, and Circuit Breakers.
Circuit Breaker State Transitions & Exponential Backoff Jitter Mechanics
System DesignPreventing cascading microservice collapse via Closed, Open, and Half-Open states
Exponential Backoff with Full Jitter
Avoids synchronized retry spikes.
- Formula: t_wait = random(0, min(max_delay, base * 2^attempt))
- Jitter randomly spreads retries over time, smoothing network traffic curves
- Never retry non-retryable 4xx client errors (e.g. 400 Bad Request, 401 Unauthorized)
Circuit Breaker Pattern
Protects failing downstream dependencies.
- Closed: Normal operation; requests pass through
- Open: Error rate threshold tripped; fast-fails immediately without hitting backend
- Half-Open: After sleep window, sends small trial probe traffic to test recovery
Resilient HTTP Client with Exponential Backoff, Full Jitter, and Deadline Timeouts
An HTTP client that retries failed requests with exponential backoff, full jitter, and enforced deadlines.
Press Run to execute the code and see output here.
9. Service Level Framework: SLA, SLO, SLI & Error Budgets
Site Reliability Engineering (SRE) balances system reliability against product feature velocity using the SLI / SLO / SLA governance framework.
SRE Service Level Hierarchy & Error Budget Governance Loop
System DesignConnecting quantitative SLI measurements, internal SLO objectives, and feature deployment velocity
SLI vs SLO vs SLA & Error Budget Governance
Aligning engineering incentives with business guarantees.
- SLI (Service Level Indicator): Quantitative measurement in production (e.g. Successful HTTP requests / Total requests = 99.94%)
- SLO (Service Level Objective): Target goal set by internal engineering (e.g. 99.9% availability over rolling 30-day window)
- SLA (Service Level Agreement): Contractual agreement with external clients containing financial refunds/credits if breached (e.g. 99.5%)
- Error Budget = 100% - SLO: The acceptable unreliability room (0.1% = ~43 mins/month). If depleted, all feature shipping stops until stability is restored
Knowledge Check
1. What is the mathematical availability of "Five Nines" (99.999%) in annual downtime?
2. What is the primary difference between RPO and RTO in Disaster Recovery?
3. Why is "Full Jitter" added to exponential retry backoff algorithms?
4. How do idempotent APIs prevent duplicate payments when network timeouts occur?
5. What action should engineering take when an Error Budget is completely exhausted?