Scalability, high availability, containers, fault tolerance and eventual consistency. Tech terms can be confusing to those new to server administration or development. In the coming weeks, we’ll be breaking down common — yet potentially confusing — terms you will undoubtedly come across in your learning journey.
Earlier on the Linux Academy blog, we addressed the topic of NoSQL databases; one of the qualities of these databases often being eventual consistency. However, what does eventual consistency actually entail? What are the benefits and trade-offs of an eventually consistent system?
Eventual consistency relies on having a distributed system, or one that utilizes multiple nodes to share the work. Centralized systems cannot be eventually consistent.
Environments that rely on eventual consistency allow for a change to happen on one of the node replicas that is eventually propagated to the other nodes. This process is not instantaneous, although the time it takes for all nodes to reach the same, updated state depends on how the nodes are configured to handle the data. This is done through synchronous messaging or asynchronous messaging.
Synchronous messaging works by opening communication between both the node that has the original update and the nodes that need to reconcile the new data. The original node will send the updates, then wait for an acknowledgement from the other node to end the transaction. This limits loss of data, although can slow down the time it takes for propagation.
Asynchronous messaging works as a one-way street. The node containing the original update will push out the changes to the other nodes, but the other nodes do not respond with an acknowledgement. This speeds up the propagation process, but there will be no apparent signal to determine if the transaction succeeded or failed.
In the time between a node receiving new information and passing it to the rest of the distributed system, the environment is considered mutually inconsistent. When all systems have reached the same state, they have achieved a state of convergence or replica convergence; convergence is not needed for the system to run successfully.
Why use a model that does not maintain constant consistency? Eventual consistency trades “instant” updating to all nodes for higher availability and faster client-side performance. Werner Vogels, CTO of Amazon, states it thus: “Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability” — this is the concession that eventual consistency makes to function at scale, and experienced systems architects and developers should work with these trade-offs to provide the best service possible with their distributed systems.