Redundancy Patterns

Why Redundancy Matters

Redundancy is the practice of duplicating critical components so that if one fails, another takes over. Without redundancy, every component is a single point of failure. The goal is not to prevent failures but to ensure that any single failure does not cause system-wide outage.

Active-Passive (Cold/Warm/Hot)

In active-passive setups, one instance handles traffic while the standby sits idle or partially ready. The standby takes over when the active fails. The recovery time depends on how warm the standby is.

Primary (Active)
  │
  │── async replication ──► Replica (Passive)
  │
  │── health check ──► Load Balancer
                           │
                      [Active] ── traffic ──► Primary
                      [Standby]              (idle)

Active-Active

In active-active, multiple instances handle traffic simultaneously. This provides both redundancy and horizontal scaling. However, it introduces complexity around data consistency, conflict resolution, and traffic routing.

1. All instances are live and accepting traffic.
2. Failover is instant — the remaining instances absorb the load.
3. Requires conflict resolution for write-heavy workloads.
4. More expensive but provides both HA and scale.

redis_cluster:
  nodes:
    - host: redis-us-east-1a
      role: primary
      region: us-east-1
    - host: redis-us-west-2a
      role: primary
      region: us-west-2
  replication:
    type: crdt          # Conflict-free replicated data types
    sync_interval: 100ms
  routing: anycast      # Nearest node handles the request

Quorum-Based Replication

Quorum-based systems require a minimum number of nodes to agree before committing a write or responding to a read. This balances consistency with availability. The classic formula: W + R > N, where W is write quorum, R is read quorum, and N is replicas.

N = 3  # Total replicas
W = 2  # Write quorum
R = 2  # Read quorum

# W + R > N → 2 + 2 > 3 → True
# This guarantees reading the latest write

# For stronger consistency:
# W = N (all replicas must acknowledge)
# R = 1 (any replica can serve reads)
# Tradeoff: higher write latency, lower read latency

Leader Election

Leader election determines which node in a cluster is the primary. Tools like ZooKeeper, etcd, and Consul use consensus protocols (Raft, Zab) to elect leaders. When the leader fails, a new one is elected automatically.

• Raft — Used by etcd, Consul, CockroachDB. Understandable and widely implemented.
• Zab — Used by ZooKeeper. Optimized for atomic broadcasts.
• Paxos — Used by Google Spanner. Theoretically foundational but complex.
• Leader leases — Prevent split-brain by making leaders renew their lease periodically.

Choosing the Right Pattern

There is no universal best pattern. The choice depends on your consistency requirements, latency budget, cost constraints, and operational complexity tolerance. Most systems use a combination.