Multi-Leader Replication: Enabling Writes Across Datacenters

Why it exists

Standard leader-based replication has a major downside: all writes must go through a single leader. If that leader is geographically distant, writes are slow. If it fails, all write operations halt until a new leader is elected. Multi-leader replication was created to solve this availability and latency bottleneck.

The mental model

Imagine a company with offices in New York, London, and Tokyo. Instead of all decisions going to a single CEO in New York, each office has its own manager who can approve local projects. Afterwards, the managers sync up via email. Projects get approved faster locally, and work doesn't stop if one manager is unreachable. The challenge is when two managers approve conflicting projects.

How it works

More than one node is designated as a leader (or master), and any of them can accept writes. When a leader receives a write, it applies the change locally and then forwards the data change to all other leaders. In this setup, every leader also acts as a follower to the other leaders. The replication between leaders is typically asynchronous, meaning the user doesn't wait for data to be copied to other datacenters, which keeps perceived performance high.

When to use it

This pattern is best for two main cases. First, multi-datacenter operations. With a leader in each datacenter, users get low-latency writes to their local leader, and the system can tolerate an entire datacenter outage. Second, applications needing offline functionality, like a calendar app. Your phone acts as a leader while offline, and when it reconnects, it syncs its changes with other leaders (like your laptop or the cloud service).

When not to use it

Avoid this setup within a single datacenter, as the complexity usually outweighs the benefits. Its biggest downside is write conflict resolution. If the same data is modified concurrently on different leaders, the conflict must be resolved. This process is complex and makes features like auto-incrementing keys, triggers, and integrity constraints very problematic. For this reason, it's often considered a dangerous pattern to be used with caution.

One canonical example

A global application has datacenters in the US and Europe, each with a leader. A European user's write request goes to the local European leader, which is fast. The change is then asynchronously replicated to the US leader. If the network link between datacenters goes down, both datacenters can continue accepting writes independently. When the link is restored, they sync up, but any conflicting writes made during the outage must be resolved.