Timestamp Oracle (TSO)

A TSO is typically implemented as a Raft- or Paxos-replicated leader service that hands out timestamps on request via a simple RPC (GetTimestamp()). The leader maintains an in-memory monotonic counter, but critically it does not grant timestamps out of thin air: it pre-allocates and persists a lease range (e.g. the next 3ms worth of logical ticks) to its replication log before serving requests from that range. This guarantees that if the leader crashes mid-lease, the new leader starts allocation strictly above the last persisted watermark, preventing timestamp reuse and the resulting MVCC visibility corruption.

In a Percolator-style transaction model (as used by TiDB’s PD component and originally Google’s Bigtable-backed Percolator), every transaction acquires a start_ts from the TSO at the beginning of the transaction to establish its read snapshot, and a commit_ts at the end to make writes visible. Because both values come from the same monotonic sequence, any two transactions can be totally ordered by comparing these timestamps, and read snapshots can filter out versions with a commit_ts greater than the reader’s start_ts. This is what allows snapshot isolation to be implemented correctly across shards that have no synchronized wall clocks at all — correctness is derived entirely from the oracle’s ordering guarantee, not from clock skew bounds.

The design trades clock complexity for a centralization bottleneck. Every transaction boundary requires a network round trip to the oracle, which becomes the hard latency floor for transaction throughput at scale. Production systems mitigate this via timestamp batching/prefetching: clients request timestamps in bulk and cache a small window locally, and the oracle itself batches persistence of lease ranges rather than fsyncing on every single tick. Failover is the sharp edge case — if the batching window is too large, a crash can “waste” a large block of timestamps (harmless for correctness but wasteful if the timestamp space is bounded), while too small a window increases the fsync/Raft-replication overhead per timestamp issued. Systems also pack a physical-time component into the high bits and a logical counter into the low bits (similar in spirit to HLCs) purely to bound namespace growth and aid debugging, not for causality tracking.

• Bottleneck scaling: a single TSO leader caps global transaction start/commit rate; some deployments shard TSOs by region with a reconciliation protocol for cross-region transactions, accepting weaker guarantees or extra coordination cost.
• Latency amplification: cross-region deployments pay a full RTT to the oracle’s leader region twice per transaction (start and commit), which is often the dominant latency cost in geo-distributed OLTP.
• GC watermark coupling: the oracle’s timestamp stream is also used to compute a safe garbage-collection watermark for old MVCC versions, so a stalled or slow-to-advance oracle can stall compaction and inflate storage.

The TSO pattern is the direct architectural counterpoint to Spanner’s TrueTime: TrueTime decentralizes ordering by giving every node a locally-derived, bounded clock uncertainty interval backed by GPS/atomic clock hardware, eliminating the oracle round trip at the cost of requiring specialized infrastructure and commit-wait delays. A TSO achieves the same total-order guarantee on commodity hardware and cloud VMs, but explicitly reintroduces a centralized dependency and RPC hop into the transaction critical path. Choosing between the two is fundamentally a decision about whether your infrastructure can afford synchronized hardware clocks versus whether your workload can tolerate a coordinated timestamp service as a first-class, highly-available component of the write path.