Multi Leader Replication

In contrast to single-leader replication, allowing multiple nodes to accept writes is known as multileader replication or active/active or master-master replication. Each node processing a write must forward the change to all other nodes, thus a leader in this scenario is also simultaneously a follower.

One of the use cases of multileader replication is when a distributed system has data spread across multiple datacenters which are geographically distant from each other. Such an architecture is usually employed to move data closer to the users or be able to withstand failure of an entire datacenter. Additionally, with single leader-based replication, the leader resides in one of the data centers and all writes must be routed through that datacenter to reach that single leader. In a multi-leader replication architecture, each datacenter has its own leader and replication within a datacenter follows the single-leader replication mechanism. However, among the datacenters, leaders from each datacenter replicate their changes to all the other leaders from distinct datacenters.

You can also think of systems such as Google Calendar, Git, Perforce, etc., that involve users working with a copy of the data offline as examples of multi-leader replication. For instance, you can be disconnected from the internet on your desktop and make changes to your calendar while being offline. The changes you made while using your desktop should reflect correctly on your mobile device, once your desktop comes back online. This is an example of a multi-leader replication at a small scale, since writes (changes) can be accepted in both the devices and are replicated to the other device. Each device acts as a leader and has its own database where changes are recorded. A device is synonymous with a datacenter and has a highly unreliable network to other devices. The replication takes place asynchronously among the device leaders and the replication lag can range wildly from a few milliseconds to days depending when a device gets back on the internet.

Another example where multi-leader replication takes place is online collaborative editing software, such as Google docs, which allows multiple users to work on a document at the same time. A user making changes on their copy of the document has the changes committed locally and then asynchronously propagated to the server and from there to the rest of users. There are several commonalities between database replication and collaborative editing software. Naturally, conflicts are expected when multiple users edit documents and there are conflict resolution strategies that we’ll delve into later.