# Vector clocks > Vector clocks track causal history so a distributed system can tell whether one event follows another or whether neither observed the other. Version vectors apply a similar idea to replicated data versions, helping systems detect conflicting writes without relying on wall-clock timestamps. Source: https://sysround.com/concepts/vector-clocks Updated: 2026-11-05 ## How vector clocks works A vector clock is a map from actor IDs to counters, such as {A: 2, B: 1}. Each actor maintains its own clock and increments its entry for each local event. Messages carry the sender's clock; the receiver takes the maximum of each corresponding entry, then increments its own entry for the receive event. Compare two clocks entry by entry, treating missing entries as zero. Clock X precedes Y when every entry in X is less than or equal to the corresponding entry in Y, with at least one strictly smaller. If X has a larger entry somewhere and Y has a larger entry elsewhere, the clocks are concurrent: neither event causally precedes the other. For example, {A: 2, B: 1} precedes {A: 3, B: 1}. But {A: 3, B: 1} and {A: 2, B: 2} are concurrent. Their timestamps do not identify a winner; they show that neither update includes the other's causal history. Version vectors summarize updates to a replicated object rather than timestamping every process event. In a simple per-object design, a write starts from the version context it observed and increments the writer's entry. Actor identities and counter allocation must prevent two independent writes from receiving the same version identity; one actor cannot create independent branches using an uncoordinated counter. A read can return a value plus its version context. The client sends that context with its next write, allowing the store to distinguish an update based on an existing version from an independent write. A later write can replace a version it dominates; concurrent versions remain as siblings until a defined conflict policy handles them. To resolve siblings, read all conflicting versions, apply an application merge or user choice, combine their vectors using entrywise maximum, and create a new version by incrementing the resolving writer's entry. Merging the counters alone does not merge the values. Deletes also need versioned tombstones so an older replica cannot simply restore deleted data. ## Worked example: Two offline edits to the same file A file starts at version {A: 2, B: 1}, which both devices have downloaded. Offline, device A edits it and produces {A: 3, B: 1}. Device B independently edits its copy and produces {A: 2, B: 2}. When they reconnect, neither vector dominates the other, so the service keeps two siblings rather than declaring the last upload correct. The user compares both files and saves a merged result through A. The service combines their histories into {A: 3, B: 2}, then increments A to produce {A: 4, B: 2}. That version dominates both siblings, allowing replicas to replace them once they receive the resolved value. ## Trade-offs - **Concurrency detection, not conflict resolution.** Vectors identify incomparable histories, but the application still needs a policy for merging values, preserving conflict copies, or asking the user. - **Metadata grows with participating actors.** Tracking many devices or writers increases storage, network, and comparison costs, even when vectors omit zero entries. - **Actor identity and counters require care.** Restarts, cloned clients, and concurrent requests must not reuse an actor-counter identity for distinct updates. - **Compaction can lose causal information.** Removing old entries without a safe retirement protocol can make ancestry and concurrency impossible to distinguish correctly. - **Available writes can accumulate siblings.** Accepting independent writes during partitions keeps the system writable but can increase conflict storage and reconciliation work. - **No global ordering or coordination guarantee.** Vector clocks do not provide linearizable reads, enforce inventory limits, or establish a total order among concurrent operations. ## When to use it in a system design interview - A replicated key-value store accepts writes on multiple replicas during a network partition and must detect conflicting versions afterward. - An offline-capable file or document system must distinguish an edit based on an old version from one based on the latest observed version. - Discarding one concurrent update using last-write-wins would lose important user data. - A design needs causal dependency tracking or a compact summary of which actor updates a replica has observed. ## How to bring it up in the interview - Start with the requirement: 'We accept independent writes and must detect conflicts rather than silently overwrite them.' Contrast this with a single leader or a conditional write against one authoritative revision. - Walk through two incomparable vectors, then explain what users see: multiple file versions, a merge prompt, or an application-specific merged value. Interviewers will probe the resolution policy, not just the comparison rule. - Define the actors and scope explicitly: per device, per replica, or per writer, and per object or across a wider history. Expect questions about concurrent writes through one actor, counter persistence, and membership changes. - Explain the client protocol: return version context on reads and require it on writes. Discuss what happens when a client omits context or writes from a stale read. - Separate detection from stronger guarantees. Expect follow-ups about sibling growth, deletion tombstones, safe metadata cleanup, and why vectors do not replace consensus or a text-editing merge algorithm. ## Common mistakes - Comparing the sum of counters or sorting vectors lexicographically, which hides concurrency instead of detecting it. - Treating entrywise maximum as a content merge; it combines causal history but says nothing about which text, file, or field values to keep. - Claiming that vector clocks prevent conflicts or automatically provide causal consistency; the system must still enforce the necessary visibility and delivery rules. - Using server arrival order or wall-clock time as proof that one write observed another. - Dropping vector entries or tombstones solely because they are old, without accounting for offline actors and stale replicas. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Version vectors let an available multi-writer store distinguish obsolete versions from concurrent siblings when replicas reconcile after partitions. - [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): Version vectors distinguish causally newer file versions from independent offline edits that require conflict preservation or merging. - [Design Google Docs](https://sysround.com/questions/design-google-docs): In a CRDT-based design, version vectors can summarize observed actor updates for causal synchronization and reconnect recovery, while the CRDT handles edit merging. ## FAQ ### What is the difference between a vector clock and a version vector? A vector clock tracks causal relationships among events in a distributed computation. A version vector summarizes the update history of a replicated object or dataset. They use similar counter comparisons, but their scope and update rules differ, so define which one your design uses. ### How do vector clocks differ from Lamport clocks? Lamport clocks use a single logical counter: if one event causally precedes another, its timestamp is smaller, but a smaller timestamp does not prove causality. Complete vector clocks can distinguish causal ordering from concurrency when all relevant causal communication is tracked. The cost is a counter per participating actor rather than one scalar. ### Do vector clocks resolve conflicts automatically? No. They identify whether versions have an ancestor-descendant relationship or represent concurrent updates. Resolving concurrent values requires an application rule, user intervention, or a suitable merge mechanism such as a CRDT. ## Related concepts - [Causal consistency](https://sysround.com/concepts/causal-consistency) - [Conflict resolution and last-write-wins](https://sysround.com/concepts/conflict-resolution) - [Lamport clocks](https://sysround.com/concepts/lamport-clocks) - [CRDTs](https://sysround.com/concepts/crdt) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.