Skip to main content

Multi-Leader Replication

What This Concept Is​

Multi-leader replication (also called active-active, master-master) has more than one node that accepts writes, with each leader replicating its writes to the other leaders. This is a qualitatively different system from single-leader:

  • Any leader accepts writes; clients can write locally.
  • Leaders forward their writes to peers (often asynchronously).
  • When two leaders independently accept writes to the same row, conflicts happen and must be resolved.

The two unavoidable problems multi-leader introduces:

  1. Topology: in what pattern do leaders send writes to each other?
  2. Conflict resolution: when two leaders disagree about the same row, which version wins, and how?
  Client-EU                          Client-US
      |                                  |
      v                                  v
  Leader-EU   <------- replication ---> Leader-US
      |                                  |
      v                                  v
   followers                          followers

Common topologies:

  All-to-all (N*(N-1) links):           Ring:                Star (hub-and-spoke):

       L1 --- L2                   L1 -> L2 -> L3              L1
       |  \  / |                      ^          |             |
       | \/   |                      |           v             C
       | /\   |                      L4 <- ... <-                         
       |/  \  |                                                / \
       L3 --- L4                                              L2  L3

Why It Matters Here​

Multi-leader trades concurrency safety for latency and availability. Every distributed SQL database that advertises "writes in any region" is doing something multi-leader-like under the hood. The conflict-handling story is where vendors diverge most.

Single-leader avoids conflicts by design. Multi-leader has them; the question is not "how do I avoid them?" but "how do I converge?"

Concrete Example​

A collaborative document editor runs leaders in us-east, eu-west, and ap-south. User Alice (EU) and user Bob (US) edit the same document title within 10 ms of each other:

  • Alice writes title = "Budget 2026 (EU)" at eu-west, commits locally in 5 ms.
  • Bob writes title = "Budget 2026 (US)" at us-east, commits locally in 5 ms.
  • Replication propagates the two updates 60 ms later.
  • Each leader sees the other's update and detects the conflict.

Conflict-resolution options:

  • Last-writer-wins (LWW): pick the update with the higher timestamp. Simple, loses data silently.
  • Custom merge: application-supplied merge function (rare in SQL, common in CRDTs).
  • Manual resolution: store both versions, surface them to the user (Dropbox-style "conflicted copy").
  • Conflict avoidance: route each user's writes to a single home leader; conflicts can only arise during failover (Bucardo, Postgres BDR).

Common Confusion / Misconception​

"Multi-leader is just single-leader with two leaders." Fundamentally different: single-leader has a single serialization point so concurrency is solvable locally. Multi-leader has no global serialization point and needs explicit convergence rules.

"LWW is safe as long as clocks are synchronized." Clocks are never perfectly synchronized. NTP skew of 10 ms is common; VM clock jumps of seconds happen. LWW with wall-clock timestamps will silently lose writes under normal operation. Vector clocks or Hybrid Logical Clocks are the honest alternatives.

"Ring replication is fine." Ring fails badly when one leader goes down; writes no longer propagate around the break. Most production multi-leader systems use all-to-all or use a coordinator.

How To Use It​

Multi-leader is the right choice when:

  1. Writers are geo-distributed and cross-region write latency is unacceptable.
  2. You have mobile or offline clients that must accept local writes and sync later (CouchDB-style).
  3. You need to tolerate datacenter loss without rejecting writes.

Avoid it when:

  • The application has invariants that cannot tolerate the "two leaders briefly disagree" window (e.g., unique constraints across regions, bank balances that must never go negative).
  • Your engineers cannot commit to writing and testing conflict-resolution code.

Check Yourself​

  1. Why does every multi-leader system need either a conflict-detection mechanism or a conflict-avoidance routing rule?
  2. What's wrong with last-writer-wins based on wall-clock timestamps?
  3. Why does ring topology have a worse failure story than all-to-all?
  4. How does "one home leader per user" avoid conflicts without giving up multi-leader's latency benefits?

Mini Drill or Application​

For each scenario, pick a topology and a conflict-resolution rule, and defend both:

  1. A Jira-like issue tracker with users in three regions; most users only edit their own issues.
  2. A globally replicated inventory counter that must not double-spend stock.
  3. A mobile note-taking app with offline editing and later sync.
  4. A multi-region user-auth database where uniqueness of emails must hold.
  5. A multi-region metrics pipeline where different metrics are produced in different regions.

Read This Only If Stuck​