Eventual Consistency Models: Release Consistency

As a data quality professional, eventual consistency is a concern. Don't get me wrong, it is a necessary and incredible programmatic feature.  However, the fact that a system can store different values for the same attribute is concerning.

Before we get into the gritty details let's define some key terms.

• Node: In a distributed system a node represents hardware which contains data and code


• Memory Object: Medium for data storage. Could be a JSON document, graph node or cached memory location

In this post, let's look at the release consistency model.  This model enforces, or maybe implements is the better word, consistency through two main operations; acquire and release.

In order to write data, a node must acquire a memory object.  When the write is complete, the node releases the memory object. 

The model is implemented by distributing all the writes across the system before another node can acquire the memory object.

There are two methods to implement release consistency; eager and lazy.  In the eager implementation writes are distributed after the node releases the memory object.  In the lazy implementation writes are distributed before a node acquires the memory object.

Eager release consistency is (potentially) more costly to the system in that it is data not necessarily required by the current users.  The upside of eager release consistency is that when the user does request the data, there is a low latency period.

Lazy release consistency essentially represents the reverse scenario.  Only required data is distributed, conserving system resources, however request latency can be high.

 Hope you enjoyed the post!  I enjoyed writing it.  Stay tuned for more write ups on eventual consistency models.