How it works
Each process maintains an integer counter, initially zero. Before each local event, including sending a message, it increments the counter. An outgoing message carries the counter value assigned to its send event.
When a process receives a message with timestamp T, it sets its counter to max(local counter, T) + 1. For example, a process at 4 that receives a message stamped 9 assigns the receive event timestamp 10.
The guarantee follows the happens-before relation: events on one process follow local execution order, a message send precedes its receipt, and these relationships are transitive. If event A happens before event B, then L(A) < L(B). Every relevant communication path must propagate timestamps for this guarantee to hold across that path.
The reverse does not hold. L(A) < L(B) does not prove that A caused B or even that B observed A. Two disconnected processes can produce timestamps 3 and 20 for unrelated events.
To define a deterministic total order, compare pairs such as (counter, process ID) lexicographically. A stable, unique process ID breaks counter ties, but this is an ordering rule, not a delivery protocol: a receiver still needs a way to know whether an earlier event might arrive later.
A worked example
Ordering a chat reply without trusting device clocks
Chat server A has counter 7. It accepts a message, increments to 8, and forwards the message with timestamp 8. Server B has counter 3; receiving that message advances B to max(3, 8) + 1 = 9. A reply created afterward gets timestamp 10, so its timestamp follows the original message even if B's wall clock is behind A's. Meanwhile, disconnected server C can independently create an unrelated message stamped 10. Comparing (10, B) and (10, C) breaks the tie deterministically but does not reveal a causal relationship. If the product requires a stable, immediately deliverable conversation order, use a per-conversation sequencing protocol rather than treating timestamp sorting as sufficient.
Trade-offs to say out loud
- Small metadata, limited information
- Each event carries one counter, plus an identifier for tie-breaking if needed, but the timestamp cannot distinguish causal dependence from concurrency.
- No synchronized clocks, no elapsed time
- Logical counters avoid wall-clock skew for ordering, but cannot measure latency, implement real-time expiration, or identify the most recent event by physical time.
- Deterministic order is not agreement
- Replicas can sort the same event set identically, but Lamport clocks do not ensure that replicas have the same events or safely commit them.
- Conflict resolution can discard valid updates
- Choosing the maximum (counter, process ID) gives a deterministic winner, but can silently overwrite a concurrent update that should have been merged or surfaced.
- Recovery and propagation require care
- A restarted logical process must preserve its counter or use a safe new identity, and all communication paths relevant to ordering must carry timestamps.
When to reach for it
- You need an ordering compatible with causal relationships, but physical timestamps are unreliable or unnecessary.
- Independent writers need a deterministic tie-breaker for replicated updates, and the application explicitly accepts the conflict-resolution policy.
- A collaborative editing design needs logical timestamps as part of operation identifiers or ordering rules within a specified CRDT.
- An interviewer asks whether timestamp ordering proves causality, detects concurrent writes, or replaces a per-partition sequencer.
How to bring it up in the interview
- Start with the required guarantee: ordering observed dependencies, detecting concurrent writes, and committing one shared order are different problems.
- Write the send and receive rules, then show a message stamped 9 advancing a receiver from 4 to 10; interviewers often check the max operation and the extra increment.
- State the one-way implication explicitly: happens-before implies increasing timestamps, not the reverse; expect a follow-up about vector clocks.
- Separate sorting from delivery: explain how a sequencer, committed log, or another protocol establishes an authoritative order or tells consumers what is safe to deliver.
- Defend the timestamp scope and recovery model: explain whether counters belong to devices, processes, or documents, how clients carry observed timestamps, and what happens after restart.
Common mistakes
- Treating a larger Lamport timestamp as proof of causality or greater wall-clock recency.
- Claiming Lamport clocks detect concurrent writes; vector clocks can represent that distinction, while scalar Lamport timestamps generally cannot.
- Assuming sorting by (counter, process ID) makes online delivery globally ordered despite delayed or missing messages.
- Using a logical timestamp as a substitute for consensus, transactional isolation, a lease deadline, or a fencing protocol.
- Assuming timestamp order alone makes concurrent text edits converge without specifying CRDT or operational transformation rules.
Where it comes up
Interview questions where lamport clocks is part of a strong answer, and why.
- Design a chat app like WhatsAppThe ordering deep dive requires distinguishing causal message order from a stable per-conversation sequence, which Lamport timestamps alone cannot provide.
- Design a distributed key-value storeAvailable writes during partitions require an explicit conflict policy, including whether logical timestamps select a winner or richer version metadata preserves concurrent writes.
- Design Google DocsIn a CRDT-based design, Lamport timestamps can support deterministic operation identifiers and tie-breaking, but the editing algorithm must separately define convergence.
Questions people ask
What is the difference between a Lamport clock and a vector clock?
A Lamport clock stores one logical counter and preserves the direction of causal relationships in timestamp order. A vector clock tracks counters for multiple participants and can distinguish causally ordered versions from concurrent versions. That extra information costs more metadata and requires managing participant identities.
Do Lamport clocks provide a total order?
Scalar Lamport timestamps can tie, so they do not uniquely order every pair of events. Adding a unique process identifier produces a deterministic total order compatible with happens-before. It does not tell a consumer that all earlier events have arrived or make replicas agree on a committed history.
What is the difference between logical clocks and physical clocks?
Logical clocks track event ordering rather than elapsed or calendar time; Lamport clocks are one type. Physical clocks approximate real time but can disagree across machines. Hybrid logical clocks combine a physical-time component with logical advancement, while still not replacing consensus or concurrent-write detection.