We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Data Replication & Distribution
A replication topology where multiple nodes accept writes independently and sync with each other. Useful for multi-datacenter setups but creates conflict resolution challenges.
In short
Multi-leader replication is a database setup where two or more nodes each accept writes independently and then replicate those writes to one another, instead of routing every write through a single primary. It lets you put a writable copy of the data in each region or datacenter, but because two leaders can change the same row at the same time, the system must detect and resolve write conflicts.
In short
Multi-leader replication is a database setup where two or more nodes each accept writes independently and then replicate those writes to one another, instead of routing every write through a single primary. It lets you put a writable copy of the data in each region or datacenter, but because two leaders can change the same row at the same time, the system must detect and resolve write conflicts.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Multi-Leader Replication across a run of lessons, not one page. These 4 alone are about 94 minutes of step-by-step reading, every one with a quiz.
Multi-master replication lets several nodes accept writes. See how it works, a concrete example of a write conflict, and when it is worth the cost.
When one writer isn't enough, multiple primaries, write conflicts, and the complexity tax you pay for global writes.
How distributed databases resolve replication conflicts: CouchDB's deterministic winner and _conflicts, Riak's mergeable siblings, last-write-wins, and merges.
How long it takes to fix the problem, from acknowledgment to all-clear.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Multi-Master Replicationpay once,
yours for life
Most replicated databases use single-leader replication: one node is the leader, it takes all writes, and read replicas (followers) copy its changes. That is simple and conflict-free, but every write has to reach that one leader, which is a problem if your users are spread across continents or if the leader goes down.
Multi-leader replication relaxes that rule. You run several leaders, often one per datacenter, and each one accepts writes locally. Each leader is also a follower of the other leaders, so writes made in London eventually flow to the leader in New York and Singapore, and vice versa.
The catch is that two leaders can accept conflicting writes to the same record before they have heard from each other. If a user in London sets a profile name to Anna while a process in New York sets it to Anne in the same window, both writes succeed locally. When the changes meet, the system has a conflict it has to resolve. Single-leader systems never face this because there is only one source of truth for ordering.
Each leader writes to its own local storage first and acks the client immediately. In the background, it ships its change log (a replication stream) to the other leaders. This is almost always asynchronous, so the regions are eventually consistent, not strongly consistent.
To stop changes from looping forever, every write carries an origin identifier, and a leader ignores any incoming change that originated from itself. Topologies vary: all-to-all (every leader talks to every other leader), circular (A to B to C to A), and star (one hub relays to the rest). All-to-all tolerates a single node failure better, but circular and star topologies can stall completely if one link breaks.
Conflict resolution is the hard part and you have to choose a strategy. Last-write-wins picks the change with the highest timestamp and silently drops the other, which is simple but loses data. Better options include keeping both versions and letting the application or user pick, merging the values (for example, union two shopping carts), or using conflict-free replicated data types (CRDTs) that are designed to merge deterministically. Riak, for instance, exposes siblings so the application can resolve them.
Reach for multi-leader replication when you genuinely need local low-latency writes in more than one geographic region, or when you need writes to keep working in a datacenter that is temporarily cut off from the others. A single leader on the other side of the world adds 100 to 300 ms to every write, which multi-leader avoids by writing locally.
The same pattern shows up in offline-first apps. A mobile device that edits data while in airplane mode is effectively a leader; when it reconnects and syncs, it is doing multi-leader replication with the server. Real-time collaborative editors like a shared document are the same problem.
The cost is real complexity. You inherit conflict resolution forever, autoincrement primary keys and uniqueness constraints become dangerous (two regions can mint the same id), and triggers or read-after-write expectations often break. Martin Kleppmann calls multi-leader setups a feature that should be used with care because of how subtly things can go wrong. If your writes can tolerate going to one region, single-leader is almost always the safer choice.
Imagine a global note-taking product with datacenters in the US, Europe, and Asia. Each datacenter runs a leader, so a user in Berlin writes to the European leader and sees their change instantly without a transatlantic round trip.
Those three leaders stream changes to each other all the time. If the transatlantic link between Europe and the US drops for two minutes, both regions keep accepting writes the whole time. When the link comes back, the queued changes flow both ways and the system reconciles them.
Now suppose the same shared note was edited in two regions during that outage. The system detects the conflict on the note row, and instead of last-write-wins it stores both edits and surfaces a merge so nothing the user typed is thrown away. That graceful behavior under partition is exactly why teams accept the extra complexity of running multiple leaders.
CouchDB
Built for multi-leader and offline-first sync; any replica can take writes and they merge back together, with conflicts exposed for the app to resolve.
BDR for PostgreSQL
Bi-Directional Replication adds asynchronous multi-master writes across PostgreSQL nodes in different datacenters.
MySQL Group Replication / circular replication
MySQL supports multi-source and ring topologies so multiple servers accept writes, though it needs careful conflict and auto-increment handling.
Riak
Stores conflicting writes as siblings using vector clocks and CRDTs so applications merge them deterministically instead of silently losing data.
Single-leader has exactly one node that accepts writes; all others are read-only followers, so there are never write conflicts. Multi-leader has several nodes that all accept writes locally and sync to each other, which gives you local low-latency writes and fault tolerance but forces you to detect and resolve conflicts.
Common strategies are last-write-wins (keep the change with the latest timestamp, but you lose the other), keeping both versions for the application or user to merge, automatic merge functions for specific data types, and CRDTs that are mathematically designed to merge without losing data. Last-write-wins is the simplest but the most dangerous because it silently drops writes.
Yes. Multi-master is the older term and multi-leader is the newer name popularized by Designing Data-Intensive Applications. They describe the same topology: more than one node accepting writes at the same time.
Two leaders can both generate the same next ID independently because they do not coordinate on every write. That creates duplicate primary keys when the writes meet. Teams avoid this with UUIDs, snowflake-style IDs, or per-leader ID ranges instead of a shared autoincrement counter.
No. Replication between leaders is asynchronous, so the system is eventually consistent. A write in one region is not immediately visible in another, and you can read stale data or hit conflicts until the regions converge.
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
CRDT
Conflict-free Replicated Data Type: a data structure that can be updated independently on different nodes and merged automatically without conflicts. Powers real-time collaboration like Google Docs.
Database Partitioning
Dividing a large table into smaller, more manageable pieces while keeping them in the same database. Sharding is partitioning across servers.
Read Replica
A copy of your database that handles read queries, reducing load on the primary database. Writes still go to the primary and replicate out.
Write-Ahead Log
A technique where changes are written to a log before being applied to the database. Ensures durability and crash recovery.
This page explains the idea. The "Multi-Master Replication" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Multi-Master Replication lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Multi-Leader Replication in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
