Related Articles

Related Articles

Eventual vs Strong Consistency in Distributed Databases
  • Difficulty Level : Medium
  • Last Updated : 23 Nov, 2020

1. Eventual Consistency :
Eventual consistency is a consistency model that enables the data store to be highly available. It is also known as optimistic replication & is key to distributed systems. So, how exactly does it work? Let’s Understand this with the help of a use case.

Real World Use Case :

  • Think of a popular microblogging site deployed across the world in different geographical regions like Asia, America, Europe. Moreover, each geographical region has multiple data center zones: North, East, West, South. 
  • Furthermore, each of zones has multiple clusters which have multiple server nodes running. So, we have many datastore nodes spread across world which micro-blogging site uses for persisting data. Since there are so many nodes running, there is no single point of failure.
  • The data store service is highly available. Even if a few nodes go down persistence service is still up. Let’s say a celebrity makes post on the website which everybody starts liking around the world. 
  • At a point in time, user in Japan likes post which increases the “Like” count of the post from say 100 to 101. At the same point in time, user in America, in a different geographical zone, clicks on the post, and he sees “Like” count as 100, not 101.

Reason for the above Use case :

  • Simply, because new updated value of Post “Like” counter needs some time to move from Japan to America and update server nodes running there. Though value of counter at that point in time was 101, the user in America sees old inconsistent value. 
  • But when he refreshes his web page after a few seconds “Like” counter value shows as 101. So, data was initially inconsistent but eventually got consistent across server nodes deployed around the world. This is what eventual consistency is.

2. Strong Consistency :
Strong Consistency simply means the data must be strongly consistent at all times. All the server nodes across the world should contain the same value as an entity at any point in time. And the only way to implement this behavior is by locking down the nodes when being updated.

Real World Use Case :



  • Let’s continue the same Eventual Consistency example from previous lesson. To ensure Strong Consistency in the system, when user in Japan likes post, all nodes across different geographical zones must be locked down to prevent any concurrent updates. 
  • This means at one point in time, only one user can update post “Like” counter value. So, once user in Japan updates the “Like” counter from 100 to 101. The value gets replicated globally across all nodes. Once all nodes reach consensus, locks get lifted. Now, other users can Like post. 
  • If the nodes take while to reach consensus, they must wait until then. Well, this is surely not desired in case of social applications. But think of stock market application where the users are seeing different prices of the same stock at one point in time and updating it concurrently. This would create chaos. Therefore, to avoid this confusion we need our systems to be Strongly Consistent. 
  • The nodes must be locked down for updates. Queuing all requests is one good way of making a system Strongly Consistent. Strong Consistency model hits capability of the system to be Highly Available & perform concurrent updates. This is how strongly consistent ACID transactions are implemented.

ACID Transaction Support :  

Distributed systems like NoSQL databases which scale horizontally on fly don’t support ACID transactions globally & this is due to their design. The whole reason for development of NoSQL tech is ability to be Highly Available and Scalable. If we must lock down nodes every time, it becomes just like SQL. So, NoSQL databases don’t support ACID transactions and those that claim to, have terms and conditions applied to them. Generally, transaction support is limited to a geographic zone or an entity hierarchy. Developers of tech make sure that all the Strongly consistent entity nodes reside in the same geographic zone to make ACID transactions are possible.

Conclusion :
For transactional things go for MySQL because it provides a lock-in feature and supports ACID transactions.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

My Personal Notes arrow_drop_up
Recommended Articles
Page :