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 Design

Calculating annual downtime thresholds and tracing automated detection and self-healing recovery phases

100%
Loading system design canvas…

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 Design

Comparing continuous load sharing against hot/warm standby failover models

100%
Loading system design canvas…

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 Design

Visualizing heartbeat timeouts, majority quorum voting (Raft/Consul), and Virtual IP remapping

100%
Rendering diagram…

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 Design

Comparing Backup & Restore, Pilot Light, Warm Standby, and Multi-Region Active-Active

100%
Rendering diagram…

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 Design

Hypothesis formulation, canary blast radius containment, fault injection, and architectural hardening

100%
Rendering diagram…

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 Design

Prioritizing critical transaction checkout flows while dropping non-essential background workloads

100%
Loading system design canvas…

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 Design

Tracing SETNX mutex locks, in-progress conflict resolution, and cached response replaying

100%
Rendering diagram…

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.

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 Design

Preventing cascading microservice collapse via Closed, Open, and Half-Open states

100%
Loading system design canvas…

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.

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 Design

Connecting quantitative SLI measurements, internal SLO objectives, and feature deployment velocity

100%
Rendering diagram…

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?