Multi-Leader Replication
A replication topology where multiple nodes accept writes independently and sync with each other. Useful for multi-datacenter setups but creates conflict resolution challenges.
What is Multi-Leader Replication?
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.
What it is
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.
How it works under the hood
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.
When to use it and the trade-offs
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.
A concrete example
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.
Where it is used in production
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.
Frequently asked questions
- How is multi-leader different from single-leader replication?
- 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.
- How are write conflicts resolved?
- 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.
- Is multi-leader the same as multi-master?
- 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.
- Why are autoincrement IDs a problem in multi-leader setups?
- 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.
- Does multi-leader give strong consistency?
- 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.
Learn Multi-Leader Replication hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Multi-Leader Replication as part of a larger topic.
See also
Related glossary terms you might want to look up next.
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.