We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Distributed Systems Core
Free preview: the first 2 parts of this 10-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Distributed Systems Core
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Quick question: what time is it? You glance at your phone. 2:14 PM. Easy. But the key point is that your phone's clock and your laptop's clock and the server in Virginia and the server in Mumbai all show slightly different times. Maybe a few milliseconds apart. Maybe a few seconds. And that tiny difference can absolutely destroy your distributed system.
In 1978, Leslie Lamport published a paper that would become one of the most cited in computer science: "Time, Clocks, and the Ordering of Events in a Distributed System." His insight was deceptively simple: you don't actually need to know what time it is. You just need to know what happened before what.
Think about it, when you're debugging a distributed system, you don't care that event A happened at 14:23:07.456. You care that event A happened before event B. The absolute time is irrelevant. The ordering is everything.
Lamport timestamps give you that ordering without requiring synchronized clocks. Every major distributed system uses some form of logical clock. Cassandra, DynamoDB, distributed databases, version control systems. Understanding Lamport timestamps is understanding the foundation of causal ordering in distributed systems.
Every node maintains a single counter, that's the entire data structure. One integer.
Rule 1: Before executing an event, increment the counter.
Rule 2: When sending a message, include the counter value.
Rule 3: When receiving a message, set the counter to max(local_counter, received_counter) + 1.
That's it. Three rules. One integer. And it gives you a powerful guarantee: if event A causally precedes event B (meaning A could have influenced B), then A's timestamp is strictly less than B's timestamp.
| Event | Rule Applied | Counter Value |
|---|---|---|
| Node A does local work | Rule 1: increment | A: 1 |
| Node A sends message to B | Rule 2: attach counter (1) | A: 1 |
| Node B receives message | Rule 3: max(0, 1) + 1 = 2 | B: 2 |
| Node B does local work | Rule 1: increment | B: 3 |
| Node B sends message to A | Rule 2: attach counter (3) | B: 3 |
| Node A receives message | Rule 3: max(1, 3) + 1 = 4 | A: 4 |
The important thing to understand: if A's timestamp < B's timestamp, it does NOT necessarily mean A happened before B. Two independent events on different nodes might have timestamps 5 and 7, but neither caused the other. Lamport timestamps capture causality in one direction only, if A happened-before B, then timestamp(A) < timestamp(B). The converse is not true.
This is the limitation that vector clocks (next lesson) were invented to solve.