Strong vs. Eventual Consistency: Understanding the Trade-offs in Distributed Systems

Following my last blog post, where I talked about the differences between relational and NoSQL databases, now I wanted to explore the differences between strong and eventual consistency, and the trade-offs involved in choosing one approach over the other.

Distributed systems offer a range of benefits, including increased scalability, fault tolerance, and performance. However, managing data consistency in distributed systems is a complex problem and strong and eventual consistency are two approaches that have emerged to tackle it.

In this article, we will cover the following questions/topics:

• What is strong consistency?
• Real world examples of SC
• What is eventual consistency?
• Real world examples of EC
• The trade-offs between the two

Strong Consistency

Simply put, strong consistency means that all server nodes in the system see the same data at the same time.

Server nodes refer to individual servers or computing nodes that are part of a distributed system.

With strong consistency, it is a requirement for data to be consistently and identically available across all server nodes globally. Meaning that at any given time, all server nodes should have the same value for a given entity. To achieve this behaviour, the nodes need to be locked down during updates, meaning that, for example, only a single node can make a database change at a time!

🔗 Attaching a great infographic about how strong consistency works with multiple nodes. I stole it from here:

Real World Examples of Strong Consistency

Consider an online banking application that allows customers to transfer money between their accounts, like Revolut or Tide.

When a customer initiates a transfer, the application needs to deduct the transfer amount from the source account and add it to the destination account. If the application is not strongly consistent, it’s possible that different nodes in the system may have different values for the source and destination accounts, leading to inconsistent or incorrect transfer amounts. As you can already acknowledge, that would give massive headaches and problems to the customer, and to the baking app.

To ensure strong consistency, the application could use a distributed lock to coordinate updates across all nodes in the system.

A distributed lock provides a way to ensure that only one node can access a shared resource or data item at a time, preventing conflicts and ensuring data consistency

When a customer initiates a transfer, the application could lock the source and destination accounts to prevent other transactions from modifying the same accounts simultaneously. Once the lock is acquired (meaning that the server node can access the shared resource safely, knowing that no other node can access it simultaneously), the application can perform the transfer and release the lock to allow other transactions to proceed.

By ensuring strong consistency, the application can ensure that the transfer amounts are accurately recorded and available to all parties involved, including the customer, the bank, and any regulatory bodies. Any inconsistency or delay in processing transactions could result in financial losses or regulatory penalties.

Eventual Consistency

On the other hand, eventual consistency allows for temporary inconsistencies between server nodes in the system, making data stores highly available.

In this approach, updates to the data are made asynchronously, and nodes may have slightly different versions of the data for a period of time. However, eventually, all nodes will converge to the same version of the data.

🔗 Another amazing infographic, but for eventual consistency. This time I stole it from here 😅

Real world examples of eventual consistency

Because most distributed system concepts are explained via e-commerce website examples, I decided to do the same 🤷‍♂…

With that said, consider an e-commerce platform, like Amazon or Ebay, that operates globally, with multiple data center zones across different regions like North America, Europe, Asia, etc. Each of these zones has multiple clusters of server nodes, including application server nodes, message queue nodes, and database nodes.

In this scenario, the database nodes play a crucial role in persisting data efficiently, ensuring that the platform is highly available even if some nodes go down.

Now imagine a scenario where a popular product goes on sale, and customers worldwide start adding it to their cart. A customer in Japan adds the product to their cart, while at the same time, a customer in the US does the same. The cart count in Japan gets updated immediately, but the US customer may not see the updated cart count immediately due to the eventual consistency model. (because the updated data hasn’t finished travelling from the node in Japan to the node in US, resulting in the US using the old data, until the newly updated data arrives from Japan)

Since the database nodes in different regions take some time to reach consensus, there may be a delay in propagating the updated cart count across all regions. As a result, the US customer may see an older cart count initially. However, eventually, the updated count will be reflected across all regions.

This feature of eventual consistency enables the platform to remain highly available and accommodate millions of customers simultaneously. Moreover, the system can add new nodes on the fly, and the database nodes remain available to the application, allowing users to perform write operations continually without locking any of the database nodes..

Eventual consistency fits best for use cases where the data accuracy doesn’t matter much, like in the use case above

⚖️ The trade-offs between strong and eventual consistency

The choice between strong and eventual consistency involves a trade-off between immediate consistency and availability/partition tolerance (the CAP theorem 👀)…

Strong consistency provides immediate consistency, but can result in higher latency and lower availability under network partitioning. In contrast, eventual consistency prioritizes availability and partition tolerance, but can lead to temporary data inconsistencies.

When choosing between strong and eventual consistency, it’s important to consider the specific requirements of your system. If your system requires immediate consistency, then strong consistency may be the better choice. However, if your system prioritizes availability and partition tolerance, then eventual consistency may be a better fit.

👋 In conclusion, I trust that this article has provided you with a comprehensive introduction to the concepts of strong and eventual consistency, and that you now have a better grasp of their trade-offs in distributed systems.

🤓 Personally, researching and writing this article has also enhanced my understanding of these concepts.

❤️ Thank you for reading, and I hope you found this article informative and useful.