Leader-follower, multi-master, eventual consistency — make distributed data reliable.
Published September 21, 2026
Replication means keeping copies of the same data on several machines. It serves three purposes:
Replication is easy while data never changes. Every hard problem comes from changes: copies are updated at slightly different moments, so at any instant they may disagree. How a system handles that gap defines its consistency behaviour, and it's one of the most important trade-offs in distributed design.
One node, the leader, accepts all writes. It records changes in a replication log (PostgreSQL's WAL, MySQL's binlog, MongoDB's oplog) that followers apply in the same order. Reads can go to the leader or the followers.
writes ─▶ Leader ──log──▶ Follower 1 ─▶ reads
└────log──▶ Follower 2 ─▶ reads
| Synchronous | Asynchronous | |
|---|---|---|
| The leader acknowledges a write after… | at least one follower has it | writing it locally |
| Write latency | Higher (a network round trip) | Lower |
| On leader crash | No acknowledged write lost | Recent acknowledged writes can be lost |
| Availability | A slow or dead follower can block writes | Followers can't block the leader |
Common middle grounds:
w: "majority", and consensus-based systems (Raft or Paxos: etcd, CockroachDB, Spanner). A write is durable once a majority has it, so any future leader elected by a majority has it too.With asynchronous followers, reads from a follower may be stale by milliseconds, or by minutes under load. Three classic problems follow:
1. Read-your-writes. A user updates their profile, refreshes, and the read goes to a lagging follower, so the old profile appears. Fixes:
2. Monotonic reads. Two refreshes hit two different followers, and the newer comment appears and then disappears. Fix: route each user consistently to the same follower (by hashing the user ID), or track the last seen position.
3. Consistent prefix. A reader sees an answer before the question it replies to, because the two writes reached different partitions in different orders. Fix: keep causally related writes in the same partition, or track causal dependencies.
// Read-your-writes by routing: recently-writing users read from the leader
public Profile getProfile(String userId) {
Instant lastWrite = recentWrites.get(userId); // e.g., a short-TTL cache entry set on write
boolean fresh = lastWrite != null && lastWrite.isAfter(Instant.now().minusSeconds(10));
return (fresh ? leaderRepo : replicaRepo).findById(userId);
}
Several nodes accept writes, typically one per data centre, and replicate to each other asynchronously.
Conflict resolution options:
Collaborative editors and offline-capable mobile apps are forms of multi-leader replication.
Any replica accepts reads and writes (Cassandra, DynamoDB's underlying design, Riak). The client or a coordinator sends each write to N replicas and waits for W acknowledgements, and reads query R replicas and take the newest version.
Quorums reduce staleness, but don't provide full linearizability by themselves. Concurrent writes and partial failures can still produce anomalies. For true linearizability, use consensus.
| Model | Guarantee |
|---|---|
| Linearizable | Behaves like a single copy: once a write completes, every later read sees it |
| Sequential | Everyone sees operations in the same order, though not necessarily in real time |
| Causal | Causally related operations appear in order everywhere. Unrelated ones may not |
| Read-your-writes / monotonic reads | Session guarantees for a single client |
| Eventual | If writes stop, replicas eventually converge. No timing guarantee |
Stronger models cost latency and availability, because they need coordination. Choose per data type: account balances and uniqueness constraints need strong guarantees, while likes and view counts are fine with eventual consistency. See CAP Theorem for the formal trade-off.
Q: Why not always use synchronous replication? A: Every write waits for a network round trip to a replica, and if the synchronous replica is slow or down, writes stall. Majority-based acknowledgement gives durability without depending on any single replica.
Q: How do you avoid split brain during failover? A: Use a consensus-based election (Raft, or a coordination service such as ZooKeeper or etcd), so only one leader can hold a majority. Attach an epoch or term number to writes, so that storage and clients reject writes from a deposed leader (fencing).
Q: What does W + R > N guarantee, and what doesn't it? A: It guarantees that read and write quorums overlap, so a read normally contacts a replica holding the latest acknowledged write. It doesn't prevent anomalies from concurrent writes, sloppy quorums or partially failed writes, so it isn't the same as linearizability.
Q: How do you give users read-your-writes consistency with read replicas? A: Route a user's reads to the leader for a short period after they write, or for their own data only. Or record the log position of their last write, and only read from replicas that have applied it.
Q: When is multi-leader replication worth its complexity? A: When you need low-latency writes in several regions, or offline operation (mobile, collaborative editing), and the data either rarely conflicts or has a natural merge rule. Otherwise, single-leader with regional read replicas is much simpler.