Eventual consistency vs Strong consistency what is the difference
Download as PPTX, PDF0 likes582 views
Eventual consistency guarantees that if an update is made to one node, the update will eventually be propagated to all other replicas. This allows for high availability, though reads may temporarily return stale data. Strong consistency ensures all replicas are immediately updated and consistent before responding to reads or writes, at the cost of reduced availability during updates. The examples demonstrate how a social media "like" count may be seen differently by users until the update propagates under eventual consistency, whereas strong consistency would delay responses until global consistency is achieved.
Eventual consistency vs Strong consistency what is the difference
- 2. Eventual Consistency vs Strong Consistency
- 3. What is Eventual Consistency? Eventual consistency is a theoretical guarantee that, provided no new updates to an entity are made, all reads of the entity will eventually return the last updated value. The Internet Domain Name System (DNS) is a well-known example of a system with an eventual consistency model. DNS servers do not necessarily reflect the latest values but, rather, the values are cached and replicated across many directories over the Internet. It takes a certain amount of time to replicate modified values to all DNS clients and servers. However, the DNS system is a very successful system that has become one of the foundations of the Internet. It is highly available and has proven to be extremely scalable, enabling name lookups to over a hundred million devices across the entire Internet.
- 4. What is Strong Consistency? In contrast, traditional relational databases have been designed based on the concept of strong consistency, also called immediate consistency. This means that data viewed immediately after an update will be consistent for all observers of the entity. To have strong consistency, developers must compromise on the scalability and performance of their application. Simply put, data has to be locked during the period of update or replication process to ensure that no other processes are updating the same data.
- 5. Eventual Consistency Use case 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 •Think of a popular microblogging site deployed across the world in different geographical regions like Asia, America, and Europe. Moreover, each geographical region has multiple data center zones: North, East, West, and South. •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 a post on the website that everybody starts liking around the world. •At a point in time, a user in Japan likes a post which increases the “Like” count of the post from say 100 to 101. At the same point in time, a user in America, in a different geographical zone, clicks on the post, and he sees “Like” count as 100, not 101.
- 6. Eventual Consistency Use case 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 •Think of a popular microblogging site deployed across the world in different geographical regions like Asia, America, and Europe. Moreover, each geographical region has multiple data center zones: North, East, West, and South. •At a point in time, a user in Japan likes a post which increases the “Like” count of the post from say 100 to 101. At the same point in time, a user in America, in a different geographical zone, clicks on the post, and he sees “Like” count as 100, not 101. •the new updated value of the Post “Like” counter needs some time to move from Japan to America and update server nodes running there. Though the value of the counter at that point in time was 101, the user in America sees old inconsistent values. •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.
- 7. Strong Consistency Use case 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. • So, once a 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 posts. • If the nodes take a while to reach a consensus, they must wait until then. Well, this is surely not desired in the case of social applications. But think of a 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. The strong Consistency model hits the capability of the system to be Highly Available & perform concurrent updates.
- 8. Eventual Consistency Whenever we use multiple replicas of a database to store data and let’s say a write request comes to one of the replicas. In such a situation, Databases had to discover a strategy to make this write request at one replica reach other replicas so that they all could also write data of the request and become consistent. Eventual consistency makes sure that data of each node of the database gets consistent eventually. Time taken by the nodes of the database to get consistent may or may not be defined. Data getting consistent eventually means it will take time for updates to reach other replicas. So what?This implies that if someone reads from a replica which is not updated yet (since replicas are updated eventually) then it may return stale data.
- 9. Strong Consistency It says data will get passed on to all the replicas as soon as a write request comes to one of the replicas of the database. But during the time these replicas are being updated with new data, response to any subsequent read/write requests by any of the replicas will get delayed as all replicas are busy in keeping each other consistent. As soon as they become consistent, they start to take care of the requests that have come at their door.
- 10. Eventual Consistency Eventual consistency guarantees that if an update is made to the data of a node (say node N), then the updated value will eventually be propagated to all the replicas of that node and eventually all the replica will become consistent to the original node(N). Nodes will get eventually consistent means it will take time for updates to reach other replicas. Hence eventual consistency is a consistency model used to achieve high availability and is a weak consistency model.
- 11. Strong Consistency In contrast to eventual consistency, Strong consistency guarantee that if an update is made to a node (say N), then the updated value will be propagated to all the replicas(N1 & N2) of the node(N), immediately in other words after the update completes, any subsequent access (to N, N1, or N2) will always return the updated value. Note during the time these replicas are being updated with new data, any read/write request to any of these replicas will get delayed as all replicas are busy in keeping each other consistent and once they will become consistent with the original node they will start accepting read/write request again.
- 12. Eventual Consistency An eventually consistent model guarantees that whenever an update is made at a node of a distributed system, it will eventually be replicated across all the nodes, as long as no new updates are made to the entity during this time. This makes the data at all the nodes consistent to the original node eventually. Eventually, all the clients will see the update. Here, the stress is on ‘eventual’, which means it can take some time before the updated value is synchronized across all the nodes.
- 13. Strong Consistency In a strongly consistent system, all the replicas are updated with the most recent value as soon as any one of the replicas responds to a write request. However, during the time interval that the data is being updated in the replicas, all read/write requests made to any of the replicas will be delayed. The replicas will only respond to the request once all the nodes receive the update. In other words, the client will get a response for their request once all the nodes of the system are consistent.
- 14. THANK YOU Like the Video and Subscribe the Channel