Latency and Consistency in Data Replication

One of the Popular interview questions is related to Latency and Data replication. The question could be about understanding the trade-offs between latency and consistency or about checking one's knowledge of the eventual consistency.

Let us try to understand the trade-offs of latency and consistency in data replication using the diagram below. Say there is an API call that is doing a write-to-DB operation; the latency, i.e. the speed to access the data, is less ( Low latency) when the data is considered to be successfully saved if only the primary (Master)DB persists data. The replica/slave DB can eventually sync with the master DB. In this case, the Latency is low, and Consistency is worse. Eventually, the slave/replicas DB will be consistent. eventual consistency allows for temporary discrepancies between replicas, favouring faster response times.

In contrast, if there is a need for strong consistency, i.e., unless all the master and slave/ replica nodes are synced, then only data is considered to be successfully saved. In this case, the speed to access the data is high; thus, Latency will be high, and consistency will be strong.

Most of the time, projects tend to strike an optimal balance between latency and data integrity to enhance the overall system efficiency and user experience. In such cases, the data is considered to be saved successfully if it can be saved in Master and one replica. In this case, the latency and consistency will be medium ( as shown in below diagram)

The trade-offs between consistency and latency are based on the project/ use case requirement. Factors such as data access patterns, application requirements, and performance/nonfunctional requirements influence the decision between strong and eventual consistency.

Applications with stringent data integrity requirements may opt for strong consistency, while those prioritizing speed may favour eventual consistency.