Performance: In case of single leader replication, all writes have to be routed to one datacenter. Imagine if the datacenter is based in the USA and a user from Asia makes a write, the request has to traverse all the way to the USA. This increases the latency for the write request and the user’s experience suffers. On the contrary, if the user’s write request is processed at a datacenter in Asia and then asynchronously replicated to datacenters across the globe, the user’s experience will be far more pleasant and the perceived performance much better. Note, we say perceived performance because for the write to be durably committed, it must be replicated in all the data centers but the user doesn’t have to wait for that to happen. The user is sent a successful write message when the user’s request is locally processed and replicated. In other words, the inter-datacenter network delay is hidden from the end-user. There is, however, the issue of data loss when an entire datacenter experiences failure and before it has had a chance to replicate its changes to other datacenters.

Datacenter Failure: In a multi-leader replication scheme, datacenters run independently of other datacenters and aren’t affected by the failures of each other. The failed datacenter can always catch up with replication when it comes back online. However, in a single-leader based replication, failure of a single datacenter can mean that a follower in another datacenter is promoted as the leader.

Network Problems: Inter-datacenter traffic usually flows over public internet infrastructure and is less reliable and prone to failures. In case of a single leader replication, write requests forwarded from peer datacenters can be delayed because of networking problems and since the write is synchronously committed, the end user can experience significant latency. Network issues between datacenters are much better handled in case of multi-leader replication, since the writes from peer datacenters are asynchronously replicated. A network partition between two datacenters doesn’t stop write requests from being processed at either of the datacenters, which is not true in case of single leader replication. If the datacenter not hosting the leader has its network link with the leader-hosting datacenter temporarily severed, a write request at the former datacenter will simply have to wait.