Back in Module 12 you saw that clocks lie. Two machines disagree about the time by a few milliseconds on a good day and by seconds on a bad one. So if Tiffin's order service logs "order created" at 20:15:00.120 and the payment service logs "payment captured" at 20:15:00.090, you cannot conclude the payment happened first. It almost certainly didn't. The payment service's clock is just behind.
Yet you often need some order of events that never contradicts cause and effect. A payment is captured because an order was created, so any log, replay or debugger should show the order first. In 1978 Leslie Lamport showed you can get exactly that with a plain integer counter and no clocks at all.
The problem: cause and effect, not time
Forget wall-clock time for a moment and think about what you actually know for sure in a distributed system:
- Inside one process, events happen one after another. Event 2 comes after event 1.
- A message is received after it was sent.
- If a comes before b, and b comes before c, then a comes before c.
Lamport called this relation happened before, written a → b. It says "a could have influenced b". If neither a → b nor b → a, the two events are concurrent: neither could have known about the other.
A Lamport clock is a counter in each process that guarantees: if a happened before b, then a's timestamp is smaller than b's.
That is the whole promise. Notice it only goes one way. We'll come back to that.