Approach 7: The TrueTime API

Why this matters: 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.

Key takeaway

Google's TrueTime API in Spanner returns a time interval [earliest, latest] instead of a specific timestamp. The system guarantees the actual time lies within that interval.

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

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.