Spanner uses TrueTime — an API that returns a bounded time interval rather than a timestamp — to provide externally consistent distributed transactions. What problem does this solve, what does it cost, and when is the cost not worth paying?

The problem it solves

In a distributed database, the order of two transactions on different machines is not knowable from local clocks, because clocks drift. The usual solutions are logical clocks (which order causally related events but not independent ones) or a single sequencer (which is a bottleneck and a failure domain).

Spanner wants external consistency: if transaction A commits before transaction B starts in real time, then A's timestamp is less than B's — even if they touched different data on different continents, with no communication between them.

How TrueTime provides it

TT.now() returns an interval [earliest, latest] guaranteed to contain the true time, with the bound maintained by GPS receivers and atomic clocks in every datacentre. The uncertainty is typically a few milliseconds.

The mechanism is then almost embarrassingly direct: a transaction picks a commit timestamp and then waits out the uncertainty interval before releasing its locks. After the wait, every subsequent transaction anywhere is guaranteed to see a later timestamp. Correctness is bought by explicitly waiting for the clock error.

What it costs

• Commit latency includes the uncertainty wait, on every read-write transaction. The system is deliberately slower to be correct, and reducing clock uncertainty is a direct latency optimisation — which is why the hardware investment exists.
• Specialised hardware in every datacentre. This is the part that does not generalise; it is why the approach appeared inside an organisation that owns its datacentres.
• Cross-region writes still pay consensus round trips. TrueTime fixes ordering, not the speed of light. A multi-region write quorum costs what geography charges.

The concession that makes it usable

Read-only transactions at a past timestamp need no locks and no coordination. They are served from any replica with a snapshot read. The overwhelming majority of real workloads are reads, so the expensive path is confined to writes — and this asymmetry is what makes the design practical rather than merely correct.

When the cost is not worth paying

When the application does not need cross-partition external consistency. A workload partitioned so that transactions stay within one entity group — one customer, one account, one order — gets serialisability from a single-partition transaction without any global ordering machinery. Most applications are of this shape and do not know it, and pay for global guarantees they never exercise.

Where it is worth paying: cross-entity invariants that must hold globally — double-entry ledgers spanning accounts in different regions, inventory decremented from multiple geographies, or any case where the alternative is a hand-written saga whose compensation logic is more expensive and less correct than the database's transaction would have been.