Approach 7: The TrueTime API

In one line: TrueTime is the only approach that scores on every column. It gets there by spending money on hardware to make physical time trustworthy — which is a genuinely different kind of answer, and worth understanding as such.

Making uncertainty explicit

Every clock is wrong; most APIs hide it. TrueTime's insight is to return the error bar rather than pretending it does not exist.

Google uses GPS receivers and atomic clocks in data centers to keep the uncertainty — epsilon — minimal, typically under 7 ms.

Every data center has time masters. GPS time masters have GPS receivers attached, and a few have atomic clocks. A client runs a daemon that contacts mostly GPS time masters and sometimes atomic clock time masters, getting redundancy from different time references.

The daemon runs Marzullo's algorithm, which intersects the time intervals to determine a reference. The API expresses the result as now plus or minus epsilon.

How epsilon grows

Uncertainty is not constant — it grows between synchronizations:

Assume the local clock drifts at most 200 microseconds per second.

Over 30 seconds:  200 us/sec * 30 sec = 6,000 us = +6 ms added to epsilon

now = reference now + local-clock offset
eps = reference eps + worst-case local-clock drift

So epsilon sawtooths: it grows at 200 µs/sec since the last sync, then drops when the daemon re-contacts a time master — typically every 30 seconds.

Ordering with intervals

Spanner guarantees order if intervals do not overlap:

If  A_earliest < A_latest < B_earliest < B_latest
then B definitely happened after A.

The honesty of the model is the point: when intervals overlap, the API does not guess — it tells you the order is undetermined. Spanner's commit-wait works by waiting out epsilon so intervals become disjoint, which is exactly why strong consistency there costs latency on every write.

Generating IDs with TrueTime

 41 bits         4 bits          10 bits      8 bits
[timestamp]   [uncertainty]     [worker]    [sequence]
 earliest T    interval width    1,024        256

Field	Bits	Purpose
Timestamp	41	Uses the earliest time of the interval
Uncertainty	4	Stores the interval width (epsilon)
Worker number	10	2^10 = 1,024 worker IDs
Sequence number	8	2^8 = 256 combinations, resetting to zero when the limit is reached

Compared to Snowflake, four sequence bits have been traded for the uncertainty field — the ID now carries its own error bar, so two IDs can be compared and you can tell whether the comparison is meaningful.

Pros and cons

	Detail
Pros	Generates globally unique, 64-bit identifiers that maintain causality. The system is scalable and highly available
Cons	If clock uncertainty intervals overlap, the relative order of events cannot be determined with confidence. The required infrastructure — atomic clocks and GPS receivers — is costly and operationally complex

The cost is the real objection

TrueTime works. It requires GPS receivers and atomic clocks in every data center, plus the daemon infrastructure and operational expertise to run them.

That is available to Google and to almost no one else. In an interview, proposing TrueTime is correct as an illustration of what's possible and usually wrong as a recommendation — unless the interviewer is asking how Spanner achieves external consistency, in which case it is exactly the answer.

Scorecard

	Scalable	64-bit numeric ID	Causality maintained
Using a range handler
Using Twitter Snowflake			weak
Using vector clocks	weak	can exceed
Using TrueTime

All five columns. The only approach that gets there — by buying hardware rather than by being clever with bits.

Key takeaway

TrueTime makes physical time trustworthy by quantifying its uncertainty instead of hiding it. That turns "the clocks disagree" from an invisible correctness bug into an explicit, bounded, checkable value.

Interview signal by level

Level	What a strong answer sounds like
L4	"Google uses atomic clocks to keep time accurate."
L5	Explains the interval: "TrueTime returns a range, not a point, and you can order two events if their ranges don't overlap."
Staff+	Names why it's honest and what it costs: "it exposes uncertainty instead of hiding it, so overlapping intervals report 'unknown' rather than guessing — and Spanner's commit-wait literally waits out epsilon, which is where its write latency comes from. It needs GPS and atomic clocks in every DC, so I'd cite it as the reference answer, not the recommendation."

Next: all seven approaches side by side.