Data replication

Leader-Follower Replication

When the query writes to the leader in a leader-follower replication, the system will replicate to one or many followers. Read queries can happen on any of the databases.
Normally 2 ways of replication in such model:
- synchronous: write query to the leader must wait for the leader and follower to commit before claiming the write query is successful.
- Asynchronous: once the write query is committed to the leader, it fires and forgets to replicate to the followers and commits the write.
In the system design interview, think about the implications for the end-user.
- If you write to the leader and read from the follower, you may design a bad user experience where the user feels like they haven’t committed because the newest data has not made it to the follower yet.
- Also, you might get inconsistent results from different read replicas if you have a load balancer that round robins between read replicas.
This might be acceptable for some applications but not for others.

If a leader fails to respond, nobody will be available to handle writes. If you’re designing an available system in a system design interview, you need to talk about handling writes when the leader fails.
Once you’ve identified that the leader is down, you can either manually configure a follower to be the leader or perform a leader election using quorum.
The downside to picking a new leader is that the process takes time. The system could be down for a couple of seconds or more because it takes time to determine a leader is down using timeouts and for a quorum election to take place. This delay might be unacceptable for some systems.

In a leader-leader configuration, there will be multiple leader nodes to take writes. The system will replicate the data to each leader to keep them up to date. Each leader can still have follower replication for backup and reads.
e writer will be more available since if one leader goes down, the other leader can take over. However, note that the performance will probably worsen because the new leader might be further away.

In a leaderless replication, supposed there aare N nodes.
- a write request (also known as quorum write) is committed to some replicas, and if at least W nodes are successful, the main write query is successful.
- A read request (also known as quorum read) reads from some of the nodes, and at least R nodes are successful before the main read query is considered successful.
W and R are tunable numbers where the higher the W and R, the greater the probability your read request will read up-to-date data.
- If R = 1 and W = N, the system is optimized for a fast read.
- If W = 1 and R = N, the system is optimized for fast write.
- If W + R > N, strong consistency is guaranteed (Usually N = 3, W = R = 2).
- If W + R <= N, strong consistency is not guaranteed.
The advantage of doing leaderless replication is you don’t have to worry about leader selection and election when the leader is down. In addition, the cluster can continue to take writes and reads even when some nodes are down. Thus, the leaderless leads to better availability.
The disadvantage of doing leaderless replication is you have to deal with the complexity of data consistency. As the write gets propagated to different nodes during quorum write, it’s unclear which update should be the winner.

Generally, the industry average is 3, but you should talk about the trade-off in an interview.
More means more cost to maintain databases, and if it’s synchronous replication, it can lower the query performances.
On the other hand, a lower count means a lower durability guarantee with fewer replicas as a backup.

To achieve high availability and reliability, data must be replicated asynchronously over N servers, where N is a configurable parameter.
These N servers are chosen using the following logic: after a key is mapped to a position on the hash ring, walk clockwise from that position and choose the first N servers on the ring to store data copies.
- (we only choose unique servers while performing the clockwise walk logic.)
Side notes: Nodes in the same data center often fail at the same time due to power outages, network issues, natural disasters, etc. For better reliability, replicas are placed in distinct data centers, and data centers are connected through high-speed networks.