What is Multi-Master Replication?
Understand multi-master replication, how concurrent writes conflict across masters, and strategies like last-write-wins and CRDTs.
Expected Interview Answer
Multi-master replication is a topology where two or more nodes can each independently accept writes and replicate them to one another, unlike single-leader replication where only one node accepts writes at a time.
Because any master can accept a write, multi-master setups give lower write latency for geographically distributed users (each region writes to its local master) and higher availability, since there is no single node whose failure blocks writes. The cost is that concurrent writes to the same record on different masters can conflict, so the system needs a conflict resolution strategy such as last-write-wins based on timestamps, version vectors, application-level merge logic, or conflict-free replicated data types (CRDTs) that merge deterministically. Multi-master is common in multi-region deployments (e.g., a user updating their profile from two different regions almost simultaneously) and in systems like CouchDB, Cassandra, and some configurations of MySQL/Postgres with logical replication. The trade-off versus single-leader replication is accepting eventual consistency and conflict-handling complexity in exchange for write availability and lower latency everywhere.
- Lower write latency since clients write to their nearest regional master
- Higher availability because no single master is a write bottleneck or single point of failure
- Survives regional outages without losing write capability elsewhere
- Suits globally distributed applications where users write from many locations
AI Mentor Explanation
Multi-master replication is like two team managers in different cities both being allowed to update the official squad list instead of only one head office doing it. If both managers add the same player to the eleven at the same time from different cities, the two lists briefly disagree until someone applies a rule — like whichever update has the later timestamp wins — to reconcile them. This setup lets each city update quickly without waiting on a single distant head office, at the cost of occasionally needing to resolve a clash. That parallel-write, eventual-reconciliation model is exactly what multi-master replication provides.
Step-by-Step Explanation
Step 1
Client writes to nearest master
A write lands on whichever master node is closest to the client, not a single fixed leader.
Step 2
Master commits locally
The receiving master applies the write immediately and acknowledges the client with low latency.
Step 3
Change propagates to other masters
The write is asynchronously replicated to the other master nodes in the topology.
Step 4
Conflicts are detected and resolved
If two masters wrote to the same record concurrently, a resolution strategy (last-write-wins, CRDTs, or app-level merge) reconciles the divergence.
What Interviewer Expects
- Explains that multiple nodes can independently accept writes, unlike single-leader replication
- Names at least one conflict resolution strategy (last-write-wins, version vectors, CRDTs)
- Discusses the availability/latency benefit versus consistency complexity trade-off
- Gives a real use case: multi-region writes, offline-first apps, or names a real system
Common Mistakes
- Assuming multi-master eliminates conflicts entirely rather than requiring resolution logic
- Confusing multi-master with simple read replicas (which cannot accept writes)
- Not mentioning any conflict resolution technique
- Overlooking that this trades strong consistency for availability and lower latency
Best Answer (HR Friendly)
“Multi-master replication means more than one server can accept writes at the same time, instead of funneling everything through a single leader. This makes the system faster and more available for users in different regions, but it means the system occasionally has to reconcile conflicting writes that happened on two servers at once.”
Code Example
function resolveConflict(localWrite, remoteWrite) {
// Each write carries a vector clock or timestamp plus node id
if (localWrite.timestamp > remoteWrite.timestamp) {
return localWrite
}
if (remoteWrite.timestamp > localWrite.timestamp) {
return remoteWrite
}
// Tie-break deterministically using node id so all masters converge
return localWrite.nodeId > remoteWrite.nodeId ? localWrite : remoteWrite
}
function applyIncomingReplica(record, incoming) {
const winner = resolveConflict(record, incoming)
store.put(winner.key, winner)
return winner
}Follow-up Questions
- How do conflict-free replicated data types (CRDTs) avoid manual conflict resolution?
- What is the difference between multi-master replication and single-leader replication with failover?
- How do version vectors detect concurrent writes across masters?
- When would multi-master replication be a poor fit for a strongly consistent banking ledger?
MCQ Practice
1. What distinguishes multi-master replication from single-leader replication?
In multi-master replication, more than one node can accept writes independently, unlike single-leader setups.
2. What problem does multi-master replication introduce that single-leader replication avoids?
Because multiple masters can accept writes concurrently, conflicting updates to the same record can occur and must be resolved.
3. Which of these is a valid conflict resolution technique for multi-master replication?
Last-write-wins (often with vector clocks or timestamps) is a common, simple conflict resolution strategy.
Flash Cards
What is multi-master replication? — A topology where multiple nodes can each independently accept writes and replicate to each other.
Main benefit of multi-master? — Lower write latency and higher availability since no single master is a bottleneck.
Main challenge of multi-master? — Concurrent writes to the same record can conflict and need resolution.
Name a conflict resolution technique. — Last-write-wins, version vectors, or conflict-free replicated data types (CRDTs).