# Lamport clocks > A Lamport clock is a logical counter that orders events without relying on synchronized wall clocks. It guarantees that a cause gets a smaller timestamp than its effect, but it cannot tell whether two events are concurrent or establish agreement between replicas. Source: https://sysround.com/concepts/lamport-clocks Updated: 2026-11-05 ## How lamport clocks 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. ## 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 - **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 use it in a system design interview - 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. ## Interview questions where it comes up - [Design a chat app like WhatsApp](https://sysround.com/questions/design-whatsapp): The 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 store](https://sysround.com/questions/design-key-value-store): Available writes during partitions require an explicit conflict policy, including whether logical timestamps select a winner or richer version metadata preserves concurrent writes. - [Design Google Docs](https://sysround.com/questions/design-google-docs): In a CRDT-based design, Lamport timestamps can support deterministic operation identifiers and tie-breaking, but the editing algorithm must separately define convergence. ## FAQ ### 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. ## Related concepts - [Vector clocks](https://sysround.com/concepts/vector-clocks) - [Hybrid logical clocks](https://sysround.com/concepts/hybrid-logical-clocks) - [Causal consistency](https://sysround.com/concepts/causal-consistency) - [Message ordering](https://sysround.com/concepts/message-ordering) --- 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.