Versioning Data and Achieving Configurability

Data versioning

When network partitions and node failures occur during an update, an object’s version historyIt contains the details of modifications of objects. might become fragmented, necessitating a reconciliation effort on the part of the system. It is necessary to build a way that explicitly accepts the potential of several copies of the same data so that we can avoid the loss of any updates. It’s critical to realize that some failure scenarios can lead to multiple copies of the same data in the system. So these copies might be the same or divergent. Resolving the conflicts among these divergent histories is essential and critical for consistency purposes.

To handle inconsistency, we need to maintain causality between the events. We can do this using the timestamps and update all conflicting values with the value of the latest request. But time is not reliable in a distributed system, so we cannot use it as deciding factor.

Using vector clocks is another approach to maintain causality effectively. A vector clock is a list of pairs of (node, counter). There is a single vector clock for every version of an object. If two objects have different vector clocks, it is possible to tell whether they are causally related or not (we will determine how to do it in the next section). Unless one of the two changes is reconciled, the two are deemed at odds.

Modifying API design

We talked about how we can decide if two events are causally related or not using a vector clock value. For this, we need information about which node performed the operation before and what was its vector clock value, i.e., the context of an operation. So we will modify our API design as follows:

• The API call to get a value should look like this:

  get(key)
  

  We will return an object or a collection of conflicting objects along with a context. The context holds encoded metadata about the object, including details such as the object’s version.

• The API call to put the value ...