Multi Leader Data Replication Architecture

Data needs to be replicated across many datacentres for high availability and redundancy. There are different architectures to do this. I covered Single Leader and follower Data Replication in my earlier post. Now I will be writing about Multi Leader Data Replication Strategy. This strategy is rarely used as it requires Conflict Resolution for final Write.

So the architecture is this

Unlike Single Leader Data Replication we have multiple leaders here. but note that there cannot be more than one leader in a particular data center as it can read to corruption of data. A single datacenter performs as a single leader follower architecture. A write destined to particular data center is processed by the leader of that data center. To keep consistency of data overall this leader then does sync up with leaders across different datacenters. As we can obviously figure out, syncing writes across different leaders may cause conflict. This reqires a conflict Resolution technique. Often rather than resolving conflict we tend to avoid conflict by allowing writes for a particular user to be processed by the same datacenter. but this will not suffice for a system where different users can write. A system such as google docs. I will discuss the semantics of google docs in a next blog but basically here we have a lock to prevent conflicts.

Systems such as calender, schedular in mobiles employ such architecture for their operation. Every mobile serves as leader in such a multi leader configuration

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.