Strong Consistency vs Eventual Consistency

In the world of databases, consistency refers to how current and synchronized your data is across multiple locations. There are two main types:

• Strong Consistency = Data is same at all the times on whichever nodes you access the data from.
• Eventual Consistency = Updates will be propagated to all the nodes eventually over time.

Let’s explore both with real-world analogies.

What is Consistency?

Consistency in system design ensures that all nodes in a distributed system maintains the same view of the data at the same time despite possible concurrent operations and network delays. In simpler terms, it means that when multiple users accessing the data from different nodes or modifying the data nodes , they all see a same view of data from all the nodes.

There are two types of consistency majorly. Let’s discuss both of them in detail:

1. Strong Consistency
2. Eventual Consistency

Strong Consistency

Strong consistency ensures that all nodes in the system see the same data at the same time, regardless of which node they are connected to. In other words, every read operation from any node after a successful write operation will return the most recent value. Strong consistency is essential for financial systems, inventory control and any system where stale data can cause harm.

Example: You transfer $100 from your bank account and you expect the updated balance to reflect the immediately otherwise you will panic when the read operation will return the stale data at any point of time.

Eventual Consistency

Eventual consistency is a property in a system design which ensures that when multiple users accessing the different nodes might see the different version of data in all the nodes. However eventually over time, updates will be propagated to the all the nodes and all nodes will reflect the same view of the data. There might be a possibility user would see the stale data in some of the nodes in any given point of time.

Let’s understand below:

Let’s consider Node A , Node B and Node C. Write operation has been done successfully on Node A . User accessing the data from Node B and Node C might see the stale data as updated data from Node A has not been propagated to Node B and Node C.

Eventual consistency works well when absolute accuracy isn’t immediately critical — like social media feeds or product recommendations.

Example: You change your profile picture on a social network. Your friend still sees the old photo — but after a few seconds, it updates. That’s eventual consistency in action.

Tradeoffs between Strong Consistency and Eventual Consistency

1. Latency :

— Strong consistency : It offers higher latency as all the nodes need to sync with same view of data at all the nodes

— Eventual consistency : It offers lower latency as data can be retrieved faster but data might be stale at any given point of time until updated data propagated to all the nodes.

2. Availability :

— Strong consistency : During network partitions or one of the nodes are offline, ensuring strong consistency will lead to unavailability as some of the replicas are not available for read and write operations. The system will always prioritise consistency over availability in such scenarios.

— Eventual Consistency : Eventual consistency allows temporary inconsistencies, which means data might be stale for a short period after an update. However, this trade-off enables high availability and allows systems to continue operating even when individual nodes or network connections are unavailable.

Finishing off here. I really hope, I made the article worth the while and you learned a lot from it.

Do consider giving this a clap since this encourages me to write more such content and share it with the world.

Do drop me a Hello!! on LinkedIn!