Version Vectors(III)

In my last article, we looked at one of the techniques of identifying concurrent updates/conflicts by leveraging Server(Replica) as an Actor & the advantages and disadvantages of doing so. If we went with the approach to include siblings in our Version Vectors to resolve conflicts, we still don’t have a way to track causality in the merged state. If we don’t include siblings in our Version Vectors, we can have data loss/updates. In this article, we’ll look at another approach for identifying concurrent updates/conflicts.

Dotted Version Vectors

Dotted Version Vectors solve the problems we saw with using ServerId. Let’s go over the problem with using ServerId -

Using ServerId for Conflict Resolution

Let’s try to understand what’s happening in the above diagram -

1. Let’s assume we have a key K, with value U. We’re assuming that we have an empty version vector, to begin with. Client’s C2 and C3 sync the same state from the Replica(Assuming all clients are interacting with the same replica) that’s implementing Version Vectors.
2. C2 updates the value to W & sends a PUT command, with the local state of Version Vector it has(empty VV).
3. C3 updates the value to V & sends a PUT command, with the local state of Version Vector it has(empty VV).
4. Replica A receives the request from C3 first(C2’s…