"What time is it?"
On a single computer, time is simple. You ask the operating system, it returns a number, and that number always moves forward. Every event gets a timestamp, and those timestamps tell you the order things happened.
In a distributed system — where your database is spread across dozens of servers in multiple data centers — time becomes a fundamental engineering problem. Each server has its own hardware clock, and those clocks drift apart. Even with synchronization protocols like NTP (Network Time Protocol), clocks across a cluster can disagree by hundreds of milliseconds.
Consider a three-node cluster:
- Server A thinks it is
10:00:00.000 - Server B thinks it is
10:00:00.250 - Server C thinks it is
09:59:59.800
These servers are not lying — they are each doing their best. But their disagreement creates a dangerous ambiguity: if you use local clocks to order events, you can get the order wrong.
The Impact on Consistency
Imagine a banking transaction spread across two nodes:
- Server A (10:00:00.000): User deposits $100. Write committed.
- Server B (09:59:59.800): User checks balance. Read executed.
Server B's clock is 200ms behind. If the database uses local timestamps to order these events, it will conclude that the "Check Balance" happened before the "Deposit" — even though in the real world it happened after. The user sees a $0 balance. The database is inconsistent.
This is not a hypothetical edge case. It is the central challenge of building a globally distributed transactional database. Every NewSQL system — Google Spanner, CockroachDB, YugabyteDB — has a specific, deliberate answer to this problem. Understanding those answers is what separates a DBRE who can operate these systems safely from one who cannot.