Hybrid Logical Clocks

The problem with pure logical clocks

Lamport clocks (Topic 5) give causal order but no tie-breaking with physical time. Vector clocks are precise but grow with replica count — expensive at scale.

Hybrid Logical Clocks (HLC) attach a logical counter to physical time so timestamps stay close to wall clock while preserving causality.

HLC structure

Each timestamp is roughly (physical_time, logical_counter, node_id):

1. On local event: l = max(physical_now, last_physical) + bump if same physical bucket
2. On receive: l = max(local, message_timestamp, physical_now)

If physical clocks are within ε (NTP/chrony disciplined), HLC respects causality and stays bounded in size (one scalar, not a vector per peer).

Where it's used

• CockroachDB — transaction timestamps, global snapshot reads
• YugabyteDB — same lineage
• TiKV — PD allocates timestamps; similar hybrid ideas

HLC vs TrueTime

	TrueTime	HLC
Clock hardware	GPS + atomic clocks	NTP/chrony with ops discipline
Commit wait	Yes (uncertainty window)	No mandatory wait
Guarantee	External consistency	Serializable with clock sync assumptions
Who runs it	Google datacenters	Anyone with good NTP

Operational requirement

HLC assumes clocks don't drift wildly. Cockroach docs require max offset monitoring (e.g. 500ms). Violations → transaction restarts or correctness risk.

Interview drill

"When would you pick HLC over vector clocks?" — Large replica count, need wall-clock-ish ordering for GC/snapshots, willing to operate clock sync.

Link to Topic 5

Lamport clocks are the foundation; HLC is the production evolution when you have mostly trustworthy wall clocks.