How does vector clock work in leaderless (or peer-to-peer) architecture?

Viewed 105

I think I have a basic understanding of vector clock, but how do we actually use it in leaderless architecture in order to solve conflict resolution?

Let's say if I have a coordinator server (e.g proxy server) talking to 3 replica nodes, and the job of the coordinator is to write data into every replica nodes (write quorum of size = 3 in this case)

             ---- replica node 1
            /
coordinator ----- replica node 2
            \
             ---- replica node 3


A vector clock is represented by a list of [replicaID, logicalClock] associated with the data. If the coordinator has successfully replicated the data, I'd imagine the vector clock would look like = <[replicaID = 1,logicalClock=1],[replicaID=2,logicalClock=1],[replicaID=3,logicalClock=1]>.

Now you proceed to update the same data, but suppose for some reasons, the coordinator failed to write the data into replica node with ID = 3. Then the vector clock would be <[replicaID = 1, logicalClock=2],[replicaID=2,logicalClock=2],[replicaID=3,logicalClock=1]> where the logicalClock with replicaID = 3 would still be 1. Then the coordinator sees that the logicalClock is off by 1 and goes ahead and resolve the inconsistency.

  1. Is my understanding correct?
  2. Where do we store vector clock? It can be either in coordinator or replica node, but I presume it makes sense to store it in the coordinator server
0 Answers
Related