Replication Strategies
Leader-follower, multi-leader, and leaderless replication — three different answers to how copies of the same data stay in sync.
Overview
Replication strategies decide how multiple copies of the same data stay in sync across nodes — leader-follower, multi-leader, and leaderless being the three standard approaches — each with a different trade-off between consistency, availability, and write throughput.
Why It Exists
A single node is both a single point of failure and a throughput ceiling. Replication exists to survive node failure and spread load across copies — but how those multiple copies agree on the current value directly determines the system's consistency and availability characteristics, which is exactly why there isn't one universally correct replication strategy.
Real World Example
A typical Postgres primary-replica setup is leader-follower: all writes go to the primary, and replicas asynchronously copy from it — this is the Read Replica concept from earlier in this journey, now viewed from the replication-strategy angle. Cassandra, by contrast, is leaderless: any node can accept a write for a given key, and the coordinator waits for a QuorumThe minimum number of nodes that must acknowledge a read or write for it to count as successful — the basis of the W + R > N rule for guaranteeing read-after-write consistency.Learn more of replicas (W) to acknowledge before considering the write successful; reads similarly query a quorum (R). As long as W + R > N (the total replica count), at least one node queried on read is guaranteed to have seen the latest write.
Example Data
Quorum math with N = 3 replicas — does W + R > N hold?
| W (write quorum) | R (read quorum) | W + R > N? | Guarantee |
|---|---|---|---|
| 2 | 2 | 4 > 3 — yes | Read always sees the latest write |
| 1 | 1 | 2 > 3 — no | A read can miss the latest write |
| 3 | 1 | 4 > 3 — yes | Slow writes, fast reads, still safe |
Three Ways to Keep Copies in Sync
Leader-Follower (Single-Leader)
One node accepts all writes; the rest asynchronously (or synchronously) copy from it. Simple to reason about, but the leader is a bottleneck for writes and a single point of failure until a follower is promoted.
Multi-Leader
Several nodes each accept writes independently and reconcile changes with each other. Improves write availability and can reduce latency for geographically distributed writers, but introduces a real conflict-resolution problem when two leaders accept conflicting writes to the same record.
Leaderless (Quorum-Based)
Any node can accept a write for a given key. Correctness is guaranteed statistically through read and write quorums rather than a single source of truth — used by systems like Cassandra and DynamoDB.
The Quorum Formula: W + R > N
N is the total number of replicas holding a piece of data, W is how many must acknowledge a write, R is how many must respond to a read. When W + R exceeds N, the set of nodes queried on a read is guaranteed to overlap with the set that received the latest write.
Diagram
Three different answers to 'who can accept a write, and how do copies agree?'
Leader-Follower
one leader, followers copy from it
Multi-Leader
several leaders, conflicts reconciled
Leaderless
any node writes, quorums decide correctness
Common Mistakes
Assuming leader-follower replication is synchronous by default
Why: Most leader-follower setups, including standard Postgres streaming replication, are asynchronous by default — the leader can acknowledge a write before any follower has it, and a leader crash right after can lose that write.
Fix: Know whether your specific replication setup is synchronous or asynchronous, and explicitly configure synchronous replication for data where losing an acknowledged write is unacceptable.
Not planning for conflict resolution in multi-leader replication
Why: When two leaders accept conflicting writes to the same record independently, something has to decide the winner — ignoring this leads to silently lost or corrupted data once conflicts actually occur.
Fix: Design and test an explicit conflict-resolution strategy (last-write-wins, custom merge logic, or manual resolution) before adopting multi-leader replication.
Choosing W and R values that don't actually satisfy W + R > N
Why: Without that inequality, a read can miss the most recent write entirely, since there's no guaranteed overlap between the nodes queried on read and the nodes that received the write.
Fix: Deliberately choose W and R so their sum exceeds N whenever the application needs strong, not eventual, read-after-write consistency.
Interview Questions
What's the difference between leader-follower and leaderless replication?
In leader-follower replication, one designated node accepts all writes and the rest copy from it. In leaderless replication, any node can accept a write for a given key, and correctness is guaranteed through read/write quorums instead of a single source of truth.
Why is W + R > N the rule for guaranteeing a read sees the latest write in a quorum-based system?
With N total replicas, requiring W acknowledgments for a write and R responses for a read, if W + R exceeds N, the set of nodes involved in any read must overlap with the set of nodes involved in the most recent write — by the pigeonhole principle, they can't both be disjoint subsets of only N nodes. That overlap guarantees at least one node in the read quorum has the latest value.
A multi-leader system gets a conflicting write to the same record on two different leaders at nearly the same time. What are the options for resolving it?
Common approaches include last-write-wins based on timestamps (simple, but can silently discard a valid concurrent update), version vectors to detect and surface the conflict for application-level or manual resolution, or custom merge logic specific to the data (e.g. merging two concurrent additions to a shopping cart instead of picking one). The right choice depends on whether losing one of the conflicting writes silently is acceptable for that specific data.
Production Best Practices
Do
✓Know whether your leader-follower setup is synchronous or asynchronous, and choose deliberately.
✓Design explicit conflict resolution before adopting multi-leader replication.
✓Choose W and R so their sum exceeds N whenever strong read-after-write consistency is required.
Don't
✗Don't assume a leader-follower crash can never lose an acknowledged write.
✗Don't adopt multi-leader replication without a tested conflict-resolution strategy.
✗Don't pick quorum values without checking whether W + R > N actually holds.
Comparison
| Who Accepts Writes? | Conflict Risk | Best For | |
|---|---|---|---|
| Leader-Follower | Only the leader | None (single source of truth) | Read-heavy workloads, simplicity |
| Multi-Leader | Multiple designated leaders | Real — needs resolution | Multi-region write availability |
| Leaderless | Any node | Resolved via quorums/versioning | High write availability, tunable consistency |