# Hybrid logical clocks > A hybrid logical clock (HLC) combines a physical-time value with a logical counter to timestamp distributed events. It preserves the order of causally related events while staying close to wall time when clock error is bounded, making it useful for replicated data and database versions. Source: https://sysround.com/concepts/hybrid-logical-clocks Updated: 2026-11-05 ## How hybrid logical clocks works Each node maintains a timestamp (p, c): a physical-time component and a logical counter. Compare timestamps lexicographically: compare p first, then c. Unlike a raw wall-clock timestamp, an HLC can advance even when the local clock moves backward. For a local event or message send, compare the current wall time with p. If wall time is greater, set p to wall time and reset c to zero; otherwise, keep p and increment c. Sending a message includes the resulting timestamp. On receipt of a message, choose the maximum of local wall time, the previous local p, and the received p. If both previous and received p equal that maximum, set c to one more than the larger counter. If only one equals it, increment that timestamp's counter; if wall time alone wins, reset c to zero. For example, node A sends an event stamped (1000, 0). Node B receives it while B's wall clock reads 995 and its previous HLC is (994, 0). B produces (1000, 1), so the receive event sorts after the send despite B's slower clock. If event A causally precedes event B through local execution and timestamp-carrying messages, HLC(A) is less than HLC(B). The reverse is not true: a smaller timestamp does not prove causation. Independent nodes can also produce identical HLCs; append a stable node identifier when a deterministic total order is needed. Applications use these timestamps to label versions or choose a deterministic winner during replication. An HLC does not deliver messages, establish agreement, or prove that all earlier writes have arrived. Those guarantees require replication, coordination, or completeness tracking around the clock. ## Worked example: Resolving replicated writes without pretending to detect conflicts Two regions accept updates to a user's display name. Region A writes “Maya” at HLC (1000, 0). Region B receives that write while its wall clock reads 992; assuming its previous HLC is smaller, it advances to (1000, 1). A subsequent local edit to “Maya Chen” gets (1000, 2) if wall time has not caught up. Replicas can therefore rank the dependent edit above the original. If a disconnected region independently writes “M. Chen” at (1001, 0), a largest-timestamp-wins policy selects that value, even though it was not based on the other edit. The interview decision is whether losing that independent edit is acceptable; otherwise, preserve conflicting versions or use stronger coordination. ## Trade-offs - **Compact timestamps, limited causal information.** An HLC uses a fixed number of fields, but unlike a vector clock it cannot distinguish concurrent events from causally related ones. - **Wall-time proximity depends on clock health.** A fast or faulty clock can push timestamps into the future, so deployments need clock monitoring and an explicit policy for excessive offsets. - **Deterministic conflict resolution can discard intent.** Choosing the largest HLC plus a tie-breaker makes replicas converge, but it can silently overwrite an independent edit. - **Ordering is not consistency.** HLC timestamps alone do not provide linearizability, serializability, or a safe cross-shard snapshot. - **Lifecycle handling adds complexity.** Counter overflow, timestamp validation, and restart behavior need explicit rules so a node does not reuse or regress timestamps where monotonicity is required. ## When to use it in a system design interview - A replicated key-value store needs compact version timestamps and an explicitly chosen last-writer-wins conflict policy. - A multi-region database needs roughly time-based version labels that also respect observed causal dependencies. - A distributed event or tracing system needs causal timestamp ordering despite clock skew, rather than relying only on raw wall time. - The design needs timestamp ordering but does not need to identify every pair of concurrent updates. ## How to bring it up in the interview - Start with the requirement: distinguish approximate wall-time ordering, causal ordering, and an authoritative commit order before proposing an HLC. - State the guarantee precisely: causally earlier events get smaller timestamps when dependencies propagate timestamps; comparing timestamps cannot establish causality. - Walk through a slow-clock receiver example, then explain how node identifiers resolve equal timestamps without creating agreement. - Separate the timestamp mechanism from the protocol: expect questions about how replicas learn writes, how readers know a snapshot is complete, and who authorizes commits. - Defend the conflict policy and operational behavior: discuss lost concurrent edits, future timestamps, clock-offset limits, and restart monotonicity. ## Common mistakes - Claiming that HLC order proves causality or identifies concurrent writes. - Treating the physical component as an exact event time or using it alone to measure request duration. - Assuming that timestamping writes makes replication linearizable or transactions serializable. - Calling the largest HLC the objectively latest real-world write, even when writers are independent and clocks differ. - Ignoring equal timestamps, excessive clock offsets, or timestamp regression after a restart. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Available writes during partitions require an explicit version-ordering and conflict-resolution policy, where HLC-based last-writer-wins is one concrete option. - [Design Dropbox or Google Drive](https://sysround.com/questions/design-dropbox): Offline edits require separating deterministic version ordering from actual concurrency detection so independent changes are not silently mistaken for dependent updates. - [Design a distributed tracing system](https://sysround.com/questions/design-distributed-tracing): Preserving causal order across skewed host clocks calls for distinguishing propagated logical timestamps from wall-clock timestamps and elapsed-time measurements. ## FAQ ### What is the difference between a hybrid logical clock and a Lamport clock? Both preserve the ordering of causally related events when timestamps travel with messages. A Lamport clock is a logical counter, while an HLC adds a physical-time component to keep timestamps near wall time under bounded clock error. Neither can infer causality from timestamp order alone. ### How do hybrid logical clocks differ from vector clocks? An HLC has a fixed number of fields and supports compact sortable timestamps. Vector clocks track multiple participants and can identify concurrency, but their metadata can grow with the participant set. Choose based on whether you need deterministic ordering or explicit conflict detection. ### Do hybrid logical clocks replace clock synchronization or consensus? No. They preserve causal timestamp order despite clock skew, but clock synchronization still matters if timestamps must remain close to real time. Consensus or another coordination protocol is still needed when nodes must agree on authoritative state or commit order. ## Related concepts - [Lamport clocks](https://sysround.com/concepts/lamport-clocks) - [Vector clocks](https://sysround.com/concepts/vector-clocks) - [Clock skew and time in distributed systems](https://sysround.com/concepts/clock-skew) - [Causal consistency](https://sysround.com/concepts/causal-consistency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.