Clocks and time in distributed systems

🕐Key Takeaways

1
Physical clocks drift — two servers can disagree on 'current time' by milliseconds to seconds
2
Lamport timestamps provide causal ordering without physical clocks (if A→B, Lamport(A) < Lamport(B))
3
Vector clocks detect concurrent events — used by DynamoDB, Riak for conflict detection
4
Google's TrueTime uses GPS + atomic clocks to bound clock uncertainty to ~7ms globally

Time Is Not What You Think

In a single computer, time is simple. In a distributed system, clocks drift, NTP corrections can jump backward, and two machines can disagree on 'now' by hundreds of milliseconds. This makes 'last write wins' based on timestamps unreliable and event ordering non-trivial.

Logical Clock Types

Each node maintains a counter. On local event: counter++. On send: attach counter. On receive: counter = max(local, received) + 1.

Guarantees: if event A causally precedes B, then Lamport(A) < Lamport(B). BUT: if Lamport(A) < Lamport(B), A might NOT have caused B (concurrent events get arbitrary ordering).

Advantages

•Lamport clocks are simple and lightweight
•Vector clocks detect true concurrency
•TrueTime enables global linearizability (Spanner)

Disadvantages

•Vector clocks grow with number of nodes
•TrueTime requires specialized hardware (GPS + atomic clocks)
•No perfect single solution for all systems

🧪 Test Your Understanding

Knowledge Check1/1

Why can't we use physical clock timestamps for event ordering in distributed systems?