Replication

Copying data across multiple nodes for availability, read scaling, and durability.

---

1. Concept Overview

Replication keeps multiple copies of data (replicas) in sync. It provides:

• High availability: If one node fails, others can serve traffic.

• Read scaling: Distribute reads across replicas.

• Durability: Data survives single-node (or single-datacenter) failure.

Why it exists: A single copy is a single point of failure and a read bottleneck. Replication addresses both.

---

2. Core Principles

Topologies

Topology	How	Use case
Leader–follower (primary–replica)	One leader for writes; followers replicate; reads can go to followers	Most RDBMS, MongoDB
Multi-leader	Multiple nodes accept writes; replicate to each other	Multi-datacenter; offline-first
Leaderless	No single leader; quorum writes and reads (e.g. W=2, R=2, N=3)	Cassandra, DynamoDB

Sync vs async replication

Mode	How	Pros	Cons
Synchronous	Leader waits for replica(s) to ack before confirming write	No data loss on leader failover	Higher latency; availability tied to replica
Asynchronous	Leader acks immediately; replicas updated in background	Low latency; leader not blocked by replica	Replica can lag; possible data loss if leader fails before replication

Architecture (leader–follower)

  Writes ──▶ Leader ──▶ Replication stream ──▶ Follower 1
                │                              Follower 2
  Reads ──▶ Follower 1 / Follower 2 (optional)

---

3. Real-World Usage

• PostgreSQL / MySQL: Primary + read replicas; async or semi-sync; failover via promotion.

• MongoDB: Replica set; one primary, secondaries replicate; automatic failover.

• Cassandra / DynamoDB: Leaderless; quorum (W, R, N); tunable consistency.

• Kafka: Partition replicas; in-sync replicas (ISR); leader handles writes.

---

4. Trade-offs

Choice	Pros	Cons
Sync replication	No loss on failover	Latency; if replica is down, writes can block or fail
Async replication	Low latency; leader not blocked	Replication lag; possible loss on leader failure
Read from replica	Scale reads	Stale reads (lag); need to handle consistency (e.g. read-your-writes)
Multi-leader	Write locally in multiple DCs	Conflict resolution; complexity

When to use: Need HA or read scaling; can tolerate eventual consistency for reads from replicas. When not: Single-node acceptable; or strong consistency with no lag (then sync and read from primary only).

---

5. Failure Scenarios

Scenario	Mitigation
Leader fails	Promote replica to leader (manual or automatic); clients reconnect to new leader
Replica lag**	Monitor lag; route critical reads to leader; increase replica capacity or reduce write load
Split brain (multi-leader)	Conflict resolution (LWW, vector clocks, CRDTs); or avoid multi-leader
Replication loop (multi-leader)	Use topology that avoids cycles; or use conflict-free structures

---

6. Performance Considerations

• Write latency: Sync replication adds round-trip(s) to replica(s); async does not.

• Read scaling: More replicas → more read capacity; balance with replication load and storage cost.

• Replication lag: Depends on write volume and replica capacity; can be seconds under load.

---

7. Implementation Patterns

• Single leader + N replicas: Standard for RDBMS; async or semi-sync; read replicas for reporting and read scaling.

• Leaderless quorum: W + R > N for strong consistency; tune W, R for latency vs durability.

• Cross-datacenter: Async replica in second DC for DR; or multi-leader if needed for local writes.

---

Quick Revision

• Purpose: HA, read scaling, durability.

• Leader–follower: One writer; replicas copy; reads can go to replicas (stale possible).

• Sync vs async: Sync = no loss, higher latency; async = low latency, possible loss.

• Leaderless: Quorum (W, R, N); no single leader; tunable consistency.

• Interview: “We use a primary and two async read replicas so writes are fast and we scale reads; we accept replication lag and route read-your-writes to the primary when needed.”