The “Clock Skew” Conflict: When Time Lies in Distributed Systems
Alice saves a document at 12:00:01 PM. Bob saves the same document at 12:00:02 PM. Your multi-master database overwrites Bob’s newer change with Alice’s older one.
The servers are healthy. The network is fine. The code is bug-free. You have just experienced silent data loss. The traitor wasn’t your infrastructure; it was time itself.
The Problem: Physical Time Is a Lie
In distributed systems, there is no global “now”. Each server possesses its own crystal oscillator, which drifts due to heat, voltage fluctuations, and age. Network Time Protocol (NTP) attempts to synchronize them, but it is probabilistic. In a modern cloud VPC in 2026, you must assume a generic clock drift of 1ms to 50ms. Across geographic regions, this widens to 100-500ms.
When your database relies on Last-Write-Wins (LWW) using physical timestamps to resolve conflicts, this drift becomes catastrophic.
The Mechanism of Failure
The fundamental flaw of LWW is the assumption that if Timestamp(A) < Timestamp(B), then event A happened before event B. In a distributed system, this axiom is false.
Consider this scenario:
Server A is running 2 seconds fast due to drift.
Bob writes to Server A at real-time 12:00:00. Server A timestamps it 12:00:02.
Alice writes to the same key on Server B at real-time 12:00:01 (physically later). Server B timestamps it correctly at 12:00:01.
Replication: The database replicates the data. It compares the timestamps:
12:00:02 > 12:00:01. It concludes Bob’s write is “newer” and discards Alice’s data.
Alice’s write happened later in physical reality, but the system’s distorted view of time caused it to be lost.
The Reality Check
