Multi-Leader Replication

Multi-Leader Replication

Multi-leader setups for multi-datacenter writes, and the conflict patterns they introduce.

Type - 2 : Multi-Leader Replication

WHAT IS MULTI-LEADER AND WHY USE IT?

Multiple servers can accept writes. Each leader replicates to other leaders.

Where is it used? - Multi-datacenter (one leader per region — writes are local and fast) - Offline apps — your phone is the leader when offline. Syncs when back online. - Collaborative editing — Google Docs. Each user edits locally. No one waits.

TOPOLOGY 1 — ALL-TO-ALL

Every leader sends writes to every other leader.

- Best fault tolerance — any leader dies, others still talk to each other.

TOPOLOGY 2 — STAR

One central HUB receives all writes and forwards to everyone else.

- Simple — all coordination through one node, easy to reason about.

TOPOLOGY 3 — CIRCULAR (RING)

Each node gets writes from prev node and passes to next: A → B → C → D → A

- Loop prevention: every write tagged with originating node ID. When write returns to that node, it recognizes its own ID and drops it. No infinite loop.

Problem with single leader across datacenters:

Write from London → must travel to NY leader → 150ms round trip on every write.

With multi-leader: London writes to local leader instantly. Syncs to NY in background.

Problem with Multi-Leader

Write conflicts. Two leaders accept different writes to the same data at the same time.

Leader A gets: UPDATE user SET name = "John" at t=10ms

Leader B gets: UPDATE user SET name = "Jane" at t=11ms

Now A and B disagree. Who wins? This is the conflict resolution problem — does not exist in single-leader.

- Ordering problem — C may get UPDATE before CREATE (use version vectors to fix).

- Single point of failure — HUB dies = entire replication stops even if all others are healthy.

- One node failure breaks the whole ring. C dies = A cannot reach D at all.