Lamport Timestamps

TechniqueIdentifiers and OrderingSeniorStaffUpdated Nov 10, 2026

Single counter per node, advanced to max(local, received) + 1 on every message. Gives total ordering of causally related events.

When to Use Lamport Timestamps

When you need 'happens-before' ordering across distributed events but don't need to detect concurrency (just to break ties consistently).

In Practice

Foundational primitive behind Paxos, Raft, and many conflict-free replicated data types (CRDTs). Cassandra uses Lamport-style timestamps for last-write-wins reconciliation.

How Lamport Timestamps Comes Up in Interviews

Scenario

You need a cheap way to consistently break ties for 'happens-before' across distributed events: a single integer per node, advanced to max(local, received) + 1 on every message. You don't need to detect concurrency, just to order things. Which primitive?

Lamport timestamps are exactly that: a single counter per node giving total ordering of causally related events. Vector clocks are heavier and add concurrency detection you said you don't need.

Lamport timestamps give you a total order on causally related events with one counter per node: the rule is 'on send, increment; on receive, set local = max(local, received) + 1.' Two events with the same Lamport timestamp aren't ordered by the algorithm, but you can break ties deterministically with node IDs. This primitive underlies Paxos's proposal numbers, Raft's term IDs, and Cassandra's last-write-wins reconciliation. Vector clocks are the cousin that also detects concurrency (at O(nodes) overhead per event), so when you only need ordering and don't care about concurrency, Lamport is the cheaper pick.