We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Distributed Systems Core
A simple logical clock where each event increments a counter. If event A causes event B, A's timestamp is always less than B's. The foundation of logical time in distributed systems.
In short
A Lamport timestamp is a single integer counter each process keeps to order events in a distributed system without a shared clock. Every process increments its counter on each event, attaches it to outgoing messages, and on receiving a message sets its counter to one more than the larger of its own value and the value in the message, which guarantees that if event A causes event B then A's timestamp is smaller than B's.
In short
A Lamport timestamp is a single integer counter each process keeps to order events in a distributed system without a shared clock. Every process increments its counter on each event, attaches it to outgoing messages, and on receiving a message sets its counter to one more than the larger of its own value and the value in the message, which guarantees that if event A causes event B then A's timestamp is smaller than B's.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Lamport Timestamp across a run of lessons, not one page. These 4 alone are about 87 minutes of step-by-step reading, 2 of them with code you run in the browser, all with a quiz.
How Lamport timestamps order events without synced clocks, using one counter per node. Includes a three-node walkthrough and Python code.
How vector clocks detect concurrent writes that Lamport timestamps miss. Includes a Python implementation and the Dynamo shopping cart example.
Monotonically increasing numbers that count events, requests served, errors thrown, bytes transferred.
Coordinate multi-step workflows across services by tracking state and routing messages through a sequence.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Lamport Timestampspay once,
yours for life
Distributed machines do not share a clock, and their physical clocks drift apart by milliseconds even with NTP running. So you cannot reliably say which of two events on two different servers happened first by comparing wall-clock times. Leslie Lamport solved this in his 1978 paper by giving each process a plain integer counter instead of a clock that tracks real time.
The counter is a logical clock. It does not measure seconds. It only measures order. The whole point is to capture the happened-before relation: if one event could have caused another, the cause must get the smaller number.
Formally, write A then B as A arrow B if they happen on the same process in that sequence, or if A is the send of a message and B is its receipt. Lamport timestamps guarantee that A arrow B implies timestamp of A is less than timestamp of B. The reverse is not true, and that limitation matters when you use them.
Each process holds one integer, usually starting at 0. Three rules drive every update.
First, before a process performs a local event, it increments its counter by 1. Second, when it sends a message, it increments its counter and stamps that value onto the message. Third, when it receives a message carrying timestamp T, it sets its counter to max of its own counter and T, then adds 1. That max step is what keeps a slow receiver from issuing a timestamp smaller than the sender it just heard from.
To get a total order with no ties, you break equal timestamps by a fixed tiebreaker such as the process id. So the full comparison is the pair of counter then process id. That turns a partial order into a total order, which is what algorithms like Lamport's original mutual exclusion need.
Reach for Lamport timestamps when you need a cheap, total ordering of events and you do not need to detect whether two events were truly concurrent. They cost one integer per process and one integer per message, which is close to free. They power things like ordering log entries, sequencing requests in a replicated state machine, and the classic distributed lock.
The trade-off is the one-way guarantee. If timestamp of A is less than timestamp of B, you cannot conclude A happened before B. A and B might be concurrent events that never influenced each other. Lamport clocks cannot tell causality apart from coincidence.
When you need to know that two writes were genuinely concurrent, for example to detect a conflict in a shopping cart or a key-value store, you need a vector clock instead. A vector clock keeps one counter per process, so it costs O of N space but can answer the concurrency question that a single Lamport integer cannot. Many real systems pick Lamport timestamps precisely because the vector clock cost grows with cluster size.
Picture three servers P1, P2, P3, all starting at 0. P1 does a local event and goes to 1. P1 sends a message to P3 stamped 2 (increment then send). Meanwhile P2 does two local events and reaches 2 on its own.
P3 has been idle at 0. It receives P1's message stamped 2, so it sets its counter to max of 0 and 2 which is 2, then adds 1 to get 3. Now if P3 emits any event, it is guaranteed a number above 2, so it can never appear to precede the P1 send that it just observed.
Notice P2 reached 2 entirely on its own with no contact with P1. P2's event at 2 and P1's send at 2 are concurrent, and equal Lamport timestamps always mean exactly that: neither event could have caused the other. The system resolves the tie by process id only because it needs a deterministic total order, not because one truly came first.
Apache Cassandra
Uses logical timestamps in the last-write-wins conflict resolution path so the highest-stamped write to a column survives across replicas.
Apache Kafka
The Raft-style controller quorum and replication rely on monotonically increasing logical offsets and epoch numbers that follow the same happened-before ordering idea.
Amazon DynamoDB and the original Dynamo paper
Dynamo popularized logical clocks for ordering writes, then moved to vector clocks where it needed to detect concurrent updates rather than just order them.
etcd and other Raft implementations
Term numbers and log indexes act as logical clocks that enforce the same causal ordering Lamport described, ensuring a follower never accepts an out-of-order entry.
A Lamport timestamp is a single integer per process and gives you a total order, but it cannot tell whether two events were concurrent. A vector clock keeps one counter per process, costs O of N space, and can detect concurrency, so you use it when you must find conflicting writes rather than just sequence them.
No. The guarantee runs only one way. If A happened before B then A's timestamp is smaller, but a smaller timestamp does not prove A happened before B. The two events may simply be concurrent, with the lower number being a coincidence.
The max step makes sure the receiver's clock is at least as large as the sender's, so it never looks like the receipt preceded the send. Adding 1 makes the receive a distinct, strictly later event than the send it observed, preserving the happened-before order.
Use a fixed secondary key, almost always the process id. Comparing the pair of counter then process id turns the partial order into a deterministic total order, which algorithms like Lamport's mutual exclusion require to pick a single winner.
No. They count events, not seconds, and the value has no connection to wall-clock time. They only encode ordering. If you need ordering that also tracks real time, hybrid logical clocks combine a physical timestamp with a Lamport-style counter.
Vector Clock
A logical clock that tracks causality across distributed nodes using a vector of counters. Each node increments its own counter and merges vectors on message receipt.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
Gossip Protocol
A peer-to-peer communication protocol where nodes share information with random neighbors, spreading it like gossip. Used for cluster membership and failure detection.
Clock Skew
The difference in time readings between clocks on different machines. Physical clocks drift; NTP helps but can't guarantee perfect sync. Why distributed systems use logical clocks.
CAP Theorem
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
Paxos
A family of protocols for solving consensus in unreliable networks. Famously difficult to understand but mathematically proven correct.
This page explains the idea. The "Lamport Timestamps" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Lamport Timestamps lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Lamport Timestamp in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
