Three replicas carry vector clocks. Replica A holds a value stamped [3,2,4] and replica B holds one stamped [3,3,3]. Say whether the two versions are ordered or concurrent, prove it from the definition, and state what the store must then do with the pair.

Three replicas carry vector clocks. Replica A holds a value stamped [3,2,4] and replica B holds one stamped [3,3,3]. Say whether the two versions are ordered or concurrent, prove it from the definition, and state what the store must then do with the pair.

Approach: Apply the componentwise comparison that defines the partial order, and check both directions before drawing any conclusion about causality.

Concurrent. A version V1 dominates V2 when every component of V1 is at least the matching component of V2 and one is strictly greater. Here [3,2,4] has the larger third component, 4 against 3, so B does not dominate A, and [3,3,3] has the larger second component, 3 against 2, so A does not dominate B. Neither dominates, so under the partial order defined by the vector clock the two are concurrent versions, descended from a common ancestor and written without either writer seeing the other. The store then has three options and must choose one explicitly. Keep both as siblings and return them on the next read, which is honest and pushes sibling reconciliation onto the application that knows the semantics, such as taking a union for a set or a maximum for a position. Merge them with a data type whose merge is commutative and associative, which removes the decision at the price of restricting what can be stored. Or resolve by last writer wins on a timestamp, which is one line of code and silently discards one of the two writes. Vector clocks detect the conflict and never resolve it.

Follow-up: How do you stop the vector from growing without bound when clients join and leave continuously?

Key concepts: vector clock, partial order, concurrent versions, sibling reconciliation.