One of the major problems of multileader replication is conflicting writes. Suppose you are editing a Google document simultaneously with a colleague sitting across the globe. One of you changes the first heading in the document from A to B and the other changes the same heading from A to C respectively. The changes by the two users are committed at the local leader in the nearest data center to each of the users. Unbeknownst to the parties, a conflicting write has been recorded for the document. Also, it can’t be said if the change from A to B is correct or the change from A to C. Both are equally valid. The conflicting write only gets detected at a later time when the write is asynchronously copied between datacenters and too late to ask either of the users to resolve the conflict.

widget

The single leader architecture doesn’t suffer from conflicting writes, since the writes are serialized and the conflicting second write can be blocked or aborted and the user forced to retry. We could potentially fix conflicting writes in a multi-leader environment by detecting a conflict synchronously. A write request is replicated to all the leaders and followers before acknowledging success. However, doing so will essentially prevent the leaders in a multileader architecture from accepting writes independently of other leaders in the system.