How do Parallel Commits reduce distributed 2PC transaction latency from 2 RTTs to 1 RTT?

In traditional Two-Phase Commit (2PC), the coordinator writes data intents across Raft ranges (Phase 1, 1 RTT), waits for acknowledgments, and then writes a COMMITTED transaction record to a designated status range before returning success to the client (Phase 2, second RTT). CockroachDB Parallel Commits pipeline this process: the transaction record is written in a special STAGING state concurrently with data write intents during the very first RTT. If all write intents successfully reach Raft consensus across their respective ranges, the transaction is implicitly committed in just 1 RTT. An explicit COMMITTED marker is written asynchronously in the background.

What is a Hybrid Logical Clock (HLC) and why is it superior to physical NTP or pure Lamport clocks?

A Hybrid Logical Clock (Kulkarni et al. 2014) combines the monotonic causal tracking of Lamport logical timestamps with the human-readable physical time of NTP clocks. An HLC timestamp is a pair (physical_time, logical_counter). If events occur within the same millisecond or if message exchanges reveal physical clock skew, the logical counter increments while keeping the physical time bound closely to true physical time. Unlike pure logical clocks, HLC timestamps can be directly correlated with real-world wall clock deadlines; unlike pure physical clocks, HLC guarantees strict causality: if event A causes event B, HLC(A) < HLC(B).

How does CockroachDB handle coordinator crashes during the STAGING phase of a parallel commit?

Because the transaction status was set to STAGING with an in-flight list of all write intent ranges, any concurrent reader encountering these intents can resolve the transaction autonomously. The reader queries each range in the staging intent list to verify whether Raft quorum replication succeeded. If all intents achieved consensus, the reader marks the transaction COMMITTED and serves the fresh data; if any intent failed or was aborted, the reader marks the transaction ABORTED. This completely eliminates coordinator single-point-of-failure deadlocks.

What is Read Restart and the Uncertainty Interval in HLC-based MVCC?

Because distributed nodes experience physical clock skew up to a maximum offset (max_offset, typically 250ms), a reading transaction cannot always determine whether a record written with a timestamp slightly ahead of the reader's clock occurred before or after the reader started. This window [reader_ts, reader_ts + max_offset] is the Uncertainty Window. If a reader encounters a value written within this window, it restarts its read operation with an updated timestamp equal to the observed value's timestamp, ensuring serializable snapshot isolation.

What are Write Intents and how do they function in CockroachDB multi-version concurrency control (MVCC)?

A write intent is an uncommitted MVCC key-value version containing an inline reference to the transaction record that created it. Write intents are replicated via Raft just like normal data, but contain a provisional lock. Concurrent readers can read through committed values behind the intent or push the transaction record if the lock owner is dead, preventing long-running write starvation.

Verified Specification | Standardized Formulas | Instant Precision

Secure & Private (Zero Data Retention) Free Access • No Sign-Up

100th Dev Tool Milestone CockroachDB Parallel Commits (1 RTT) Hybrid Logical Clocks (HLC)

Distributed Transactions: CockroachDB Parallel Commits & HLC Studio

Master distributed ACID consensus without Google TrueTime atomic clocks. Explore how CockroachDB achieves sub-50ms distributed writes by collapsing Two-Phase Commit (2PC) into 1 RTT Parallel Commits, tracking causal causality via Hybrid Logical Clocks (HLC), and self-healing from mid-commit coordinator crashes.

1. Multi-Region Cluster Architecture & Hybrid Logical Clocks

Node 1 (US-East) - Coordinator Gateway

HLC: 1774000000.000, c=0

Physical Wall Clock: 10:45:00.000
Status: Online & Serving
Txn Record: None

Node 2 (EU-West) - Range A Raft Leader

HLC: 1774000000.012, c=0

Keys: accounts:balance_A
RTT to Coord: 72 ms
Write Intent: Empty

Node 3 (AP-South) - Range B Raft Leader

HLC: 1774000000.008, c=0

Keys: audit_log:record_B
RTT to Coord: 140 ms
Write Intent: Empty

2. Protocol Execution Timeline & Latency Comparison

Distributed Protocol Trace

Cluster ready. Click "Run Parallel Commit (1 RTT Fast Path)" to execute a cross-region transaction.

Latency Profile & Consensus Milestones

Commit Protocol Mode: Parallel Commits
Consensus Round-Trips: 1 RTT
Total Client Perceived Latency: 140 ms
Coordinator Status: Active
Recovery Mechanism: None Required

⚠️ 5 Fatal Traps in Distributed Transactions & HLC Architecture

1. Physical Clock Jump Exceeding Maximum Offset (max_offset Panic)

If VM hypervisor migration or broken NTP synchronizers cause a server's clock to skew beyond --max-offset (typically 250ms), the node immediately suicides with a hard fatal crash. This strict fail-stop behavior prevents data anomalies that would otherwise shatter linearizability.

2. Unbounded Read Restart Cascades in Hot-Spot Ranges

When hundreds of concurrent readers touch a single account balance record being written by a node with a forward-skewed clock, every reader enters the Uncertainty Window, triggering repeated read restarts. In high-concurrency workloads, this creates severe CPU thrashing and multi-second transaction retries.

3. Abandoned Write Intents Blocking Concurrent Readers

If a coordinator crashes without logging staging intent locations, write intents remain locked indefinitely. Concurrent transactions attempting to read those keys must execute intent resolution loops, sending RPCs to push the dead transaction record, introducing latency spikes for subsequent readers.

4. Raft Quorum Loss During Phase 1 In-Flight Writes

If an entire datacenter hosting 2 out of 3 Raft replicas loses power while intents are in-flight, the range loses quorum. Neither the coordinator nor concurrent readers can verify whether intents reached consensus, freezing the transaction until the quorum is restored or manually discarded.

5. Cross-Region Cross-Range Cartesian Contention

Transactions touching keys distributed across multiple global continents (e.g. US, EU, Tokyo) are bound by the speed of light between the furthest two replicas. Developers attempting high-throughput writes across widely scattered geographic ranges will hit physics limits unless localized range leasing or table partitioning is enforced.

Distributed Transactions: CockroachDB Parallel Commits & HLC Studio

1. Multi-Region Cluster Architecture & Hybrid Logical Clocks

2. Protocol Execution Timeline & Latency Comparison

⚠️ 5 Fatal Traps in Distributed Transactions & HLC Architecture

1. Physical Clock Jump Exceeding Maximum Offset (max_offset Panic)

2. Unbounded Read Restart Cascades in Hot-Spot Ranges

3. Abandoned Write Intents Blocking Concurrent Readers

4. Raft Quorum Loss During Phase 1 In-Flight Writes

5. Cross-Region Cross-Range Cartesian Contention

🔍 Companion Workbenches & Verification Tools

Linux EEVDF Kernel Scheduler & Virtual Deadline Studio

CSS Box Shadow Generator

Kubernetes Gateway API, Ingress & Service Mesh Architecture Studio

CSV to JSON Converter & Delimited Table Parser

Why Smart Users Are Switching to This Free Toolkit

The Browser Feature Most People Never Use

Stop Paying for Software You Can Get Free

File Conversion Tricks That Save Hours Every Week

This Free Tool Replaced 5 Paid Apps for Our Team

What Your Browser Can Do Without Any Extensions