DatabasesAdvancedguidePart 2 of 4 in Distributed Systems Mastery

Hybrid Logical Clocks (HLC): Solving Distributed Time & Causality

Why physical timestamps fail in distributed systems. Learn how Hybrid Logical Clocks (HLC) combine physical time and logical counters to maintain strict causal order.

Sachin SarawgiApril 20, 20262 min read2 minute lesson
Recommended Prerequisites
Consistent Hashing: The Secret Sauce of Distributed Scalability

Hybrid Logical Clocks (HLC): Mastering Time

In a distributed system, time is a lie. Due to Clock Drift, no two servers have perfectly synchronized clocks. If Server A records an event at 10:00:01 and Server B records a subsequent event at 10:00:00, your system has "violated causality."

To solve this, we use Hybrid Logical Clocks (HLC).

1. Why Physical Clocks Fail

Network Time Protocol (NTP) can synchronize clocks within a few milliseconds, but in a system processing 100,000 requests per second, a few milliseconds is an eternity.

  • Clock Smearing: NTP slowly adjusts the clock.
  • Clock Jumps: NTP abruptly resets the clock, potentially moving it backward.

2. The HLC Structure

An HLC timestamp consists of two parts:

  1. Physical Component (pt): The wall-clock time from the OS.
  2. Logical Component (l): A counter that increments when physical time stands still or moves backward.

3. The HLC Algorithm

When a node receives or generates a new event:

  • Rule 1: new_physical = max(current_physical, last_physical, incoming_physical).
  • Rule 2: If new_physical is greater than last_physical, reset the logical counter to 0.
  • Rule 3: If new_physical equals last_physical, increment the logical counter.

4. Why this matters: Causal Ordering

HLCs provide Causal Consistency. If Event A caused Event B, HLC guarantees that HLC(A) < HLC(B). This is essential for:

  • CockroachDB: Uses HLC for its multi-version concurrency control (MVCC).
  • Conflict Resolution: Deciding which update happened "first" in a master-less cluster (like Cassandra).

Summary

Hybrid Logical Clocks are the bridge between the physical reality of hardware and the logical requirements of distributed software. By combining the best of both worlds, HLC allows us to maintain the arrow of time across thousands of independent nodes.

Learning Path: Databases Track

Keep the momentum going

Step 22 of 54: Your next milestone in this track.

Next Article

NEXT UP

Inside the Linux Page Cache: The Invisible Database Accelerator

2 min readAdvanced

📚

Recommended Resources

Designing Data-Intensive ApplicationsBest Seller

The definitive guide to building scalable, reliable distributed systems by Martin Kleppmann.

View on Amazon
Kafka: The Definitive GuideEditor's Pick

Real-time data and stream processing by Confluent engineers.

View on Amazon
Apache Kafka Series on Udemy

Hands-on Kafka course covering producers, consumers, Kafka Streams, and Connect.

View Course

Practical engineering notes

Get the next backend guide in your inbox

One useful note when a new deep dive is published: system design tradeoffs, Java production lessons, Kafka debugging, database patterns, and AI infrastructure.

No spam. Just practical notes you can use at work.

Sachin Sarawgi

Written by

Sachin Sarawgi

Engineering Manager and backend engineer with 10+ years building distributed systems across fintech, enterprise SaaS, and startups. CodeSprintPro is where I write practical guides on system design, Java, Kafka, databases, AI infrastructure, and production reliability.

Continue Series

Distributed Systems Mastery

Lesson 2 of 4 in this learning sequence.

Next in series

Keep Learning

Move through the archive without losing the thread.

Related Articles

More deep dives chosen from shared tags, category overlap, and reading difficulty.

DatabasesBeginner

The CDC Playbook: Real-time Syncing between PostgreSQL and Elasticsearch

The CDC Playbook: Zero-Delay Data Syncing How do you keep your search engine (Elasticsearch) updated when a user changes their profile in your primary database (PostgreSQL)? Dual-writing in your application code is a rec…

Apr 20, 20261 min read
PlaybookDistributed Systems Mastery
#cdc#debezium#postgresql
System DesignAdvanced

Speculative Retries: The Google Approach to Solving Tail Latency

Speculative Retries: Solving the P99 Tail In a large distributed system, the "tail latency" (P99.9) is often dominated by a single "slow" node. This is the Tail at Scale problem. No matter how much you optimize your code…

Apr 20, 20262 min read
Deep DiveDistributed Systems Mastery
#system-design#low-latency#p99
DatabasesAdvanced

Database Sharding Part 4: Consistent Hashing Internals

Database Sharding Part 4: Consistent Hashing Internals In Part 3, we successfully identified userid as our shard key. Now, we must write the mathematical algorithm that routes an incoming query containing userid: 1045 to…

Apr 20, 20265 min read
Deep DiveDatabase Sharding Mastery
#consistent-hashing#distributed-systems#algorithms
DatabasesAdvanced

Database Sharding Part 5: The Scatter-Gather Problem

Database Sharding Part 5: The Scatter-Gather Problem When you implement a sharded database architecture, you establish a primary Shard Key (as discussed in Part 3) to route your queries. If your Shard Key is userid, retr…

Apr 20, 20265 min read
Deep DiveDatabase Sharding Mastery
#query-optimization#sharding#latency

More in Databases

Category-based suggestions if you want to stay in the same domain.