Scalability : Single Leader Replication

As we know that there are 2 types of replication :

1. Asynchronous Replication
2. Synchronous Replication

With synchronous replication, data is written to the primary storage and the replica simultaneously. In contrast, with asynchronous replication, data is first written to primary storage and then to the replica.

We usually deal with Asynchronous Replication usecases .

Single Leader Replication :

It is known as Replication schema , it means its a way to send writes to the database and basically reading from it later .

So in the below example , All writes no matter who is sending it , will first go to the leader database , and as we see we have many follower databases then it will be asynchronously replicated to the follower database .

As we can see the Actor(client) can read from both the follower databases .

Benefit of Single Leader Replication :

1. Increased Read throughput : Now instead of reading it everytime from leader database , we have follower databases in the image attached we can see the read throughput has now increased to 3X times , as we have one leader and 2 followers which will increase the read throughput
2. Many copies of the database : Increase durability , if one of the follower goes down , we still have data available with other followers .

Failure Scenerios :

Scenerio : When Follower goes down

This situation can be handled easily as other followers as well as Leader will have the information already available in replication Log .

Replication Log : This log is basically sent from leader to all followers and contains the position till when the write operation is performed from leader to each followers .

Let us suppose a scenerio where Follower 1 goes down , and last seen on replication log was from 50–70 , but on others it was from 71–80 , So when follower 1 comes up . It can check the replication log find out that last write on it was from 50–70 and then it will start from 71–80 . In this manner the sync between leader and follower which goes down and then comes up can be done .

Scenerio : When Leader goes down

This is a cumbersome situation and in this case the recovery is little difficult .

1. Scenerio : Leader/Follower -1/Follower-2 (Network Connection Issue)

Suppose connection between Follower-1 and Leader is broke , and Follower-1 thinks that Leader is dead

Now that may be a situation that network issue between Follower-1 and leader is there , but then Follower-1 dont know when leader will gonna communicate to it as replication is asynchronous between Leader and follower -1

2. Scenerio : Leader/Follower -1/Follower-2 (Data integrity Issue)

We might think that just because we have single leader replication then every write will go through leader and eventually to followers we dont have any lost write usecase .

But No , Suppose leader has replication log with last write as 80

But Follower-1 has replication log with last write till 70 only .Now the leader goes down , and you have made Follower-1 as New Leader L1 .

But it has last write till 70 only , so those data from 71–80 is lost and that could lead to datat integrity issue .

3. Scenerio : Leader L1/ Follower-1 converted to new Leader L2(Split Brain Issue)

Suppose by any chance Leader 1 goes down and now Follower -1 has been converted to new Leader L2 , but now by chance Leader -1 comes back and is working absolutely fine .

Now other followers will become confuse from whom to take write instruction from , this situation is called Split brains.

Also some writes would go to L1 and other to L2 .

Split brain is Major Data Integrity Situation when system is bound to have one leader but some nodes are coming up and some going down making the system to have more than one leader and a chaotic situation between read and write among leader and followers.

Conclusion :

When Follower goes down , we have options available to make our system of single leader replication still work properly .

But when leader goes down , it becomes little difficult situation , we have to agree on the Distributed Consensus in order to make our single leader replication model work properly .

For increasing the write throughput , Single leader Replication might not be the best choice as although it ensures increase in read throughput but not in write throughput , we have to opt for Multi-leader replication approach .