Using the Eventually Trait

In this lesson, we’ll learn how to make our tests robust in eventually-consistent systems.

Strong consistency vs. eventual consistency

In a distributed system, data is typically replicated across multiple nodes for availability, fault tolerance, and scalability. However, when data is replicated across multiple nodes, the nodes might not always agree on the current state of the data. This can lead to inconsistencies in the system. Consistency models provide a way to define the level of agreement that nodes in a distributed system should have about the current state of the data. There are various consistency models, but the two most commonly used are strong and eventual consistency.

Strong consistency guarantees that all nodes in the system see the same version of data at the same time, regardless of which node is accessed. In other words, if a write operation is performed on one node, all subsequent reads on any node will return the updated value. Strong consistency ensures that all operations on the data will be seen as atomic and executed in a sequential manner as if they were being performed on a single node. It’s commonly used in financial systems and others that require high levels of data integrity and accuracy.

But strong consistency can sometimes lead to increased latency and reduced availability as nodes wait for confirmation from each other. For example, if a node performing a write operation is unavailable or experiencing high network latency, other nodes might have to wait for the operation to complete before they can access the data. This can lead to decreased performance and availability in the system.

To have strong consistency, you have to sacrifice the scalability of the system because the data must be locked during an update to avoid concurrent updates of the same information. Furthermore, the data must be locked during the replication of the update to make sure that all nodes see the most recent update.