Vector Clocks

TechniqueIdentifiers and OrderingSeniorStaffUpdated Nov 10, 2026

Each node maintains a counter; events carry a vector of counters that captures partial causal ordering.

When to Use Vector Clocks

Detecting concurrent updates in a distributed store. Two versions with incomparable vectors are concurrent (a conflict); one strictly dominates the other if its vector is >= in every position.

In Practice

Riak and DynamoDB use vector clocks (Dynamo paper). When you GET a key and see two versions, you reconcile, same primitive amazon.com uses for shopping cart merge.

How Vector Clocks Comes Up in Interviews

Scenario

In Amazon's Dynamo paper, a GET on a shopping cart can return multiple sibling versions that the client must reconcile. The system detects two writes as concurrent when their version metadata is incomparable. What is that metadata?

Vector clocks (one counter per node) let you detect concurrent updates: if neither vector dominates, the versions are concurrent siblings. Lamport timestamps give a total order but can't distinguish concurrent from causal.

Vector clocks attach one counter per node to each version, letting the system distinguish causal updates (one version dominates the other) from concurrent updates (neither dominates, these are siblings that need application-level reconciliation). Dynamo's original paper describes the shopping-cart case explicitly: two adds from different sessions might both succeed against different replicas, and the next GET surfaces both versions with their vector clocks so the client can union them. Riak still uses vector clocks; modern DynamoDB has moved to last-write-wins by default but preserves the conceptual lineage. Lamport timestamps can totally order events but can't tell you which ones were concurrent, which is exactly what conflict reconciliation needs to know.