Multi-leader: writes everywhere, conflicts included
Single-leader has a geographic flaw: if the leader lives in Frankfurt, every write from Tokyo pays a ~250ms round trip, and if Frankfurt's region goes dark, the whole planet stops writing. Multi-leader replication puts a leader in each location. Every leader accepts writes locally and asynchronously exchanges changes with the others.
You buy two enormous properties — local write latency everywhere, and surviving a region loss without failover — and you pay with the deepest problem in this course: two leaders can accept different writes to the same record at the same moment, and both are already committed. Everything in this lesson is either enjoying the purchase or paying the bill.
Where it's actually used
Multi-region databasesDynamoDB global tables, Aurora Global (write forwarding), CockroachDB in some modes, classic MySQL circular setups. One logical table, writable on several continents.
Offline-capable clientsYour phone's calendar is a leader: it accepts writes on a plane and syncs later. Every device + the server = multi-leader, whether the app's author realizes it or not.
Collaborative editingGoogle Docs / Figma: every user's session is a leader making local edits, merged continuously. The extreme case — conflicts every second, resolved by design.
Topology: who ships changes to whom
With more than two leaders you must choose the shape of the replication graph — and the shape determines what a single node failure does to change propagation:
Kill a node, watch the topology cope
Pick a topology, then click node B to kill it and send a change from A. Does it still reach everyone? Revive B and try the others.
Verdicts: all-to-all is the robust default — no single node is structurally special — at the cost of more streams and the possibility of changes arriving out of order along different paths (systems attach version metadata to reorder). Circular and star minimize connections, and both turn one node into a single point of partition for replication itself — MySQL's classic ring earned its scars this way.
The bill: concurrent write conflicts
Two leaders, same record, same moment, different values — both locally committed before either hears of the other. Detection is easy (version metadata reveals that neither write "happened before" the other). Resolution is the design decision. There are exactly three families:
One conflict, three resolutions
EU sets the shared doc title to "Q3 Plan" while US sets it to "Q3 Roadmap", concurrently. Pick a strategy, fire the conflict, and note who pays.
Notice what LWW quietly assumes: comparable clocks across regions. Clock skew of a few milliseconds silently redefines "last" — a write that physically happened second can lose to one with a fast clock. LWW is honest engineering only when the data is overwrite-friendly (settings, presence, caches). Siblings (Riak's model, CouchDB's conflict revisions) never lose data but push work to every reader. Domain rules are powerful and dangerously easy to get wrong under retry and replay.
The fourth way: make conflict impossible
CRDTs — conflict-free replicated data types — are data structures whose concurrent updates commute: apply them in any order on any replica and you converge to the same value, no resolution step at all. The catch: you must express your data as one of these types (counters, sets, registers, sequences — the machinery inside Figma-style collaborative apps and Redis CRDB).
A counter that cannot conflict
This is a G-Counter: each region increments its own slot, and the value is the sum of all slots. Click both regions in any order, as unfairly as you like, then merge. Try to make them disagree — you can't.
EU replica state
{eu:0, us:0} = 0
US replica state
{eu:0, us:0} = 0
The honest rule of multi-leader: it's a superb architecture for data that is overwrite-safe, mergeable, or partitioned by nature (each user writes their own records in their own region) — and a trap for data with invariants spanning writers, like balances, stock counts, or uniqueness constraints. If two regions must agree before committing, you don't want multi-leader; you want Lesson 4.
Check yourself
1. A mobile note-taking app syncs edits made offline on a phone and a laptop. Which architecture is this, whether the developer knows it or not?
Any device that accepts writes while disconnected is a leader with extreme replication lag (hours on a flight). The sync step is multi-leader conflict resolution, which is why naive note apps duplicate or clobber notes — they shipped multi-leader without a conflict strategy.
2. DynamoDB global tables use last-writer-wins. Which data is the worst fit?
Two regions concurrently decrement stock=5 → both write 4 → LWW keeps "4" and a sale vanishes from the count. Preferences are overwrite-safe; unique-key appends never collide. LWW's silent-discard behavior must match what the data means.
3. Why does a G-Counter never conflict, while "read the value, add 1, write it back" does?
Read-modify-write races on the same cell; the G-Counter decomposes the value so writers never touch each other's state, and merge is a commutative, idempotent max. That's the CRDT design move in general: restructure the data so concurrency becomes harmless instead of arbitrated.