Eventual Consistency vs Strong Consistency

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

THANK YOU
Like the Video and Subscribe the Channel