What is Eventual Consistency?
Let’s understand the definition of Eventual Consistency from an example:
Consider you have an app similar to Instagram where users can post their photos and followers can see photos posted by users they follow.
To speed up and to reduce latency you copy the data to multiple servers across the globe. Users get data they want to see from the nearest server based on their location.
Now consider, your location is India and you use the server placed in India and you have a friend in Australia who uses a server placed in Australia when using the app.
Imagine on one bad day the network between Australia and India got disconnected for a day.
Now in this case when you open the app, you may not see the latest photos posted by your friend in Australia. And similarly, your friend who is in Australia, may not see the latest pictures posted by you.
At a later point in time, when the network is restored, updates are propagated to all servers and you see the latest photos posted by your friend and similarly, your friend will see your latest posts.
The system has eventually become consistent.
Definition from Wikipedia: Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.
Is Eventual Consistency just to take care of network partitioning?
Eventual consistency is not just about network partition, but even when there is no network partitioning, an eventually consistent system will immediately return the call to the user after updating one of the nodes.
Such a system will not wait for all the nodes of the system to have the latest data.
The user gets the faster response in this case, as a request for writing data gets an immediate response from the server, after the server writes data to its own database and don’t wait for data to be replicated to other servers before responding back to the user.
What is Strict Consistency?
String consistency means that when a write operation is received from a user, his or her call is blocked till all the nodes of the system are not updated with the latest data. This also means that all the readers are also blocked from reading this specific data value until all nodes have the latest information.
Why not use Strict consistency all the time ?
Please note that when using strict consistency, user calls get blocked till data is replicated to all systems. This may be fine behavior in a few cases but may not be in all cases.
- If you are creating a system like Instagram or Facebook, where if a user is not seeing the latest data for few seconds, it is fine, you may go ahead with Eventual Consistency.
- If you are creating a banking or trading system, you have to see the latest information all the time, though you are ok if your call gets blocked for 3 sec. In such a scenario, you will use Strict Consistency.
Can you give me more examples where eventual consistency is used in systems we use day to day?
Photo sharing app like Instagram
- Let’s consider a photo-sharing application like Instagram which stores a copy of the photos in nodes A and B.
- When a user uploads a new photo, it might get uploaded to node A.
- Another user querying node B for photos will NOT see the new photo uploaded by user A till node A is able to propagate the new photo to node B.
- However, the new photo does eventually propagate to node B and user B will be able to eventually query for it.
- Depending on the system, this propagation might take a few seconds to few hours.
Social media like Facebook or Twitter or Linkedin Posts Timeline
- When you post a status message on social media, it might not be immediately visible to your friends or followers. But eventually, they’ll be able to see the status updates/ tweets.
DNS (Domain Name System)
If you have ever bought a domain name and updated its settings then you will know about this. If you update your DNS settings, you will get the message that these settings will replicate across other DNS servers in the next 24 hours.
Can we configure databases to have eventual or strict consistency?
Most commercial NoSQL databases offer different consistency levels such that you don’t have to choose just between Eventual and Strict consistency. This gives you flexibility in configuring the database as per your user requirements.
Azure Cosmos DB offers five levels of consistency ranging from Strict to Eventual consistency.
Cassandra comes with tunable consistency. This allows the client application connecting with Cassandra, to decide how consistent the requested data must be for any given read or write operation. Cassandra also allows you to have a separate consistency strategy for reading and write operations.
Can you give example of other databases which provide eventual consistency?
AP systems provide eventual consistency:
- Dynamo DB