Vector Clocks and Lamport Timestamps Lab (Interactive)
Send messages between three nodes, then compare any two events for happened-before or conflict. Build a distributed event history with Lamport counters and vector clocks side by side, and watch Lamport order pretend concurrency is sequencing.
Lamport & Vector Clock Causality Bench
Fire local events and messages on three clock-drift-free nodes, then pick any two events: does a Lamport inequality imply causality — or does the vector clock reveal a concurrent conflict?
No events yet. Create local events on A and B without messaging, then compare them: neither VC dominates → concurrent siblings, exactly like a Dynamo conflict.
How It Works Under the Hood
Without synchronized physical clocks, causality is tracked logically: Lamport timestamps give a total order that agrees with happened-before but cannot detect concurrency — t1 < t2 does not mean t1 caused t2. Vector clocks fix precisely that blind spot by keeping a per-node counter merged pointwise on receive, so comparison of two clocks answers before, after, or concurrent, which is exactly the input a conflict resolver needs. This lab lets you generate local events and cross-node messages, renders both clock types per event, and lets you pick any two events to classify their relationship under both schemes.
Core Architectural Principles
- Local events tick the node counter; message receipt merges pointwise max plus tick.
- Pairwise comparison classifies before, after, concurrent, or identical under each clock.
- Lamport vs vector disagreement counter exposes how often total order hides real conflicts.
Use vector clocks to answer conflict-detection questions in versioning designs: “two document versions are concurrent iff neither clock dominates, so we fork.” Add the practical caveat: clocks grow with node count, which is why production systems often fall back to hybrid logical clocks or generation ids.
Vector clocks buy true concurrency detection at the cost of O(N) metadata carried in every message.