Multi-Leader Replication

Several nodes accept writes and replicate to each other. Why you would want that, why it creates write conflicts, and the ways to avoid or resolve them.

Overview

In multi-leader replication, more than one node accepts writes. Each leader applies a write locally, confirms it, and then sends it to the other leaders in the background. It is also called active-active or master-master replication.

This buys local writes in several places and writes that keep working when one site is cut off. It costs something single-leader replication never has: two leaders can change the same data at the same time, and the system has to decide what the result is.

When one leader is not enough

Users in several regions — Each region writes to its own leader, so writes skip the long round trip to one far-away primary
A region or its link goes down — Other regions keep accepting writes; changes sync when the link returns
Offline-capable apps (phone, laptop) — Each device is a leader for its local copy and syncs later
Real-time collaborative editing — Each user's edits apply at once locally and merge with others'

Inside each region, the leader usually has its own followers, so each region looks like a normal single-leader setup.

The core problem: write conflicts

Because leaders confirm writes before telling each other, two users can change the same record in two regions and both be told 'saved'. When the changes cross, each leader must decide which value to keep. Neither user can be warned in time: the conflict is found only after both writes were confirmed.

Avoid conflicts first

The simplest fix is to make conflicts impossible for most data. Give each record a home leader: route all writes for one user, one account or one document to the same region. Then only one leader ever writes that record, and it behaves like single-leader replication for that record. The exception is when the home region fails, or a user moves, and writes for a record briefly land on two leaders.

Some systems remove conflicts another way: they order writes across nodes before committing them. MySQL Group Replication in multi-primary mode lets every member accept writes, but it checks concurrent transactions against each other (certification). If two change the same row, the one ordered first commits and the other is rolled back. That avoids silent merges, at the cost of coordinating on every commit.

Resolving conflicts that do happen

Every replica must end in the same state, so the resolution rule must be deterministic. These are the main choices.

Last write wins (LWW) — Keep the value with the highest timestamp or ID — Silently drops the other write; wall clocks can be skewed
Keep all versions — Store every conflicting version, let the app or user merge — App code must handle siblings
Custom merge in the app — A handler combines values, such as the union of two carts — Must be written per data type; removals are tricky
CRDT — A data type whose merge always gives the same result, in any order — Only for data that fits a CRDT: counters, sets, text, maps

CouchDB is an example of keeping all versions. After replication both conflicting revisions exist on both sides. CouchDB picks a winner with a deterministic algorithm so every node shows the same one, and flags the others in _conflicts so the application can merge and delete the losers.

CRDTs: merges that cannot conflict

A CRDT (conflict-free replicated data type) lets any replica change its copy without coordinating, and guarantees that two replicas that have seen the same updates end in the same state. A grow-only counter shows the idea: each replica counts only its own increments, and merging takes the larger count for each replica.

The merge is commutative, associative and idempotent, so the order and repetition of syncs do not matter. A PN-counter pairs two of these to allow decrements, and an observed-remove set (OR-set) handles adds and removes of the same element.

Replication topologies

With more than two leaders, the path a change takes matters.

Ring (circular) — Few links — One failed node breaks the chain until it is rerouted
Star (hub) — Simple to reason about — The hub is a single point of failure
All-to-all — No single point of failure — Changes can take different paths and arrive out of causal order

The order of delivery matters: if leader 1 inserts a row and leader 2 then updates it, leader 3 may receive the update before the insert. Tagging each change with a version vector (one counter per leader) lets a node see that the update depends on an insert it has not yet applied, and wait for it.

What you will be able to do

Name the situations that justify several leaders, and say when a single leader is still better.
Explain why conflicts appear only after both writes were confirmed.
Avoid most conflicts by giving each record a home leader.
Compare last write wins, keeping versions, custom merges and CRDTs.
Explain why all-to-all replication can deliver changes out of order.

Key concepts

Multi-leader (active-active): Several nodes accept writes and replicate them to each other asynchronously.
Write conflict: Two leaders accept different changes to the same data concurrently; found only when the changes meet.
Home leader: Routing all writes for a given record to one leader, so that record cannot conflict in normal operation.
Last write wins (LWW): Keep the change with the highest timestamp. Converges, but silently discards the other write and trusts clocks.
Siblings: Conflicting versions kept side by side until the application merges them.
CRDT: A conflict-free replicated data type: replicas update without coordination and always converge to the same state.
Replication topology: The paths changes take between leaders: ring, star or all-to-all.
Version vector: One counter per leader attached to a change, used to tell whether one change depends on another or they are concurrent.

When to use it

Designing an active-active, multi-region database.
Explaining conflict resolution for offline-first or sync-based apps.
Discussing CRDTs for collaborative editing or distributed counters.
Arguing why a single-leader design is simpler when write latency across regions is acceptable.

Interview questions

How do you handle write conflicts in a multi-leader database?
Why is last write wins dangerous?
When would you choose multi-leader over single-leader replication?
Explain a CRDT to someone who has not seen one.
What ordering problem appears with all-to-all replication, and how is it handled?