Multi-Leader Replication

Why this matters: the moment two nodes can accept a write to the same record, you have a conflict problem that no amount of engineering fully removes — only manages. Knowing the three ways to manage it is the point of this lesson.

Key takeaway

Single-leader replication bottlenecks all writes to one node. Multi-leader replication lets multiple nodes accept writes and replicate them to each other, improving write scalability and fault tolerance — at the cost of write conflicts.

The model

It is particularly useful for applications that must function offline. A calendar app is the canonical example: the local device acts as a leader, accepting writes with no network at all, and syncs changes when connectivity returns. Under a single-leader model those writes would simply fail.

Pattern	Purpose
Bidirectional	Reporting instance
Unidirectional	Instant fail-over
Peer-to-peer	Load balancing for high availability
Broadcast	Wide-level data distribution to multiple instances
Consolidation	Data warehouse — data storage

The conflict

The main disadvantage is the risk of write conflicts. If two clients modify the same data concurrently at different leaders, the system must resolve the discrepancy.

Both writes succeeded locally. Both leaders then learn the other made a different change to the same record. Neither is wrong; there is simply no single answer, and the system must pick one.

Handling conflicts

Conflicts must be resolved efficiently to prevent data loss. Three common strategies:

Conflict avoidance

The most straightforward approach: avoid write conflicts altogether by routing all writes for a given record to a single leader.

It works well and it is fragile in a specific way: if traffic is redirected — because a client relocates or a node fails — writes may reach different leaders and conflicts appear exactly when the system is already under stress.

Last-write-wins (LWW)

Nodes assign a timestamp to every update. On conflict, the update with the latest timestamp wins.

Simple, and prone to data loss due to clock skew in distributed systems.

Custom logic

The application defines its own conflict-handling logic, executed on read or on write. The system might merge the conflicting data, or prompt the user to resolve it manually.

Merging is the reason a shopping cart is the classic example — the union of two carts loses nothing, so an item added on a phone and another added on a laptop both survive. Prompting is what version-control conflicts do.

Strategy	How it resolves	Data loss risk	Use it for
Conflict avoidance	Never creates one — pin writes per record to one leader	None while routing holds	Records with a natural home (per-user data)
Last-write-wins	Highest timestamp survives	High — clock skew silently discards writes	Caches, presence, disposable state
Custom logic	Merge, or ask the user	Low — nothing is discarded blindly	Carts, documents, anything a user would notice losing

Replication topologies

Topologies define how updates propagate between leaders. Common types are circular, star, and all-to-all.

All-to-all is the most robust. In star and circular topologies, a single node failure can interrupt the replication flow — every message in a circular topology passes through its neighbors, and every message in a star passes through the hub, so losing one node severs paths for others.

All-to-all avoids that single dependency, at the cost of more connections and the possibility of messages arriving out of order along different paths.