Database Replication: Models, Consistency, and Tradeoffs
Replication copies the same data across multiple database nodes for high availability, read scaling, and fault tolerance. Models include single-leader (leader-follower), multi-leader, and leaderless (quorum). The core tradeoff is between synchronous replication (consistent but slower, blocks on followers) and asynchronous (fast but allows replication lag and data loss on failover).
What Replication Is and Why
Replication keeps copies of the same dataset on multiple nodes. Unlike sharding (which splits data), replication duplicates it, so every replica can serve reads and survive node failure. It provides high availability, disaster recovery, read scalability, and lower latency by placing replicas near users.
Replication is essential for any system that can't tolerate downtime: if the primary fails, a replica is promoted. It also offloads read traffic, common in read-heavy apps where you route writes to a leader and reads to many followers.
Replication Models
The replication topology determines where writes are accepted and how conflicts (if any) are resolved. Single-leader is the simplest and most common; leaderless trades simplicity for availability.
- Single-leader (leader-follower / primary-replica): all writes go to one leader, which streams changes to followers. Simple, no write conflicts; used by PostgreSQL, MySQL, MongoDB. The leader is a write bottleneck and SPOF until failover.
- Multi-leader: multiple nodes accept writes (e.g., one per datacenter). Better write availability and locality, but introduces write-write conflicts requiring resolution (last-write-wins, CRDTs).
- Leaderless (Dynamo-style): any replica accepts reads/writes; consistency comes from quorums. Used by Cassandra, DynamoDB, Riak. Highly available but requires read repair and conflict handling.
Synchronous vs Asynchronous, and Replication Lag
Synchronous replication waits for follower(s) to confirm before acknowledging a write, guaranteeing the data survives leader failure but adding latency and reducing availability if a follower is slow. Asynchronous replication acknowledges immediately and propagates in the background, which is fast and the common default, but on leader failure recent unreplicated writes can be lost, and followers serve stale reads due to replication lag.
Semi-synchronous is a middle ground: wait for at least one follower (common in MySQL). Replication lag causes read-your-writes problems, where a user updates data, then reads a stale follower. Fixes include reading from the leader after writes, monotonic reads, or tracking the replicated log position.
| Model | Write availability | Consistency | Conflict handling |
|---|---|---|---|
| Single-leader | Limited (one leader) | Strong on leader | None needed |
| Multi-leader | High | Eventual | Required (LWW/CRDT) |
| Leaderless | High | Tunable (quorum) | Read repair |
Quorums and Failover
Leaderless systems use quorum math: with N replicas, a write succeeds on W nodes and a read queries R nodes; if W + R > N, reads and writes overlap on at least one node, guaranteeing the read sees the latest write. A typical config is N=3, W=2, R=2. Tuning W and R trades consistency against availability and latency.
Failover promotes a follower to leader when the leader dies, coordinated by tools like Patroni, Orchestrator, or built-in mechanisms. Risks include split-brain (two leaders accept writes) and lost writes; consensus protocols (Raft, Paxos) provide safe automated failover.
ResuMax tailors your resume to each role, scores it like a recruiter, and preps you for interviews.
Practice with the interview coachFrequently asked questions
What's the difference between replication and sharding?
Replication copies the full dataset to multiple nodes for availability and read scaling. Sharding splits the dataset across nodes for write and storage scaling. Large systems combine both: each shard is replicated.
What is replication lag and why does it matter?
Replication lag is the delay before a write on the leader appears on asynchronous followers. It causes stale reads and read-your-writes anomalies. Mitigate by reading from the leader after a write or using monotonic/read-your-writes consistency guarantees.
What does W + R > N mean in quorum systems?
In a leaderless system with N replicas, writing to W nodes and reading from R nodes guarantees an overlap (so reads see the latest write) when W + R > N. For example N=3, W=2, R=2 gives strong-ish consistency while tolerating one node failure.
What is split-brain in failover?
Split-brain occurs when a network partition causes two nodes to both believe they're the leader and accept conflicting writes. Consensus protocols like Raft or Paxos, plus fencing tokens, prevent it by ensuring only one leader can be elected at a time.