In One Example, 90ms of Clock Skew Made Last-Write-Wins Keep the Older Write

That comparison inverts under one condition: the real-time gap between two writes has to be smaller than the disagreement between the two clocks that stamped them ^[1][2]. At the 90 milliseconds in the post's example, any two updates to the same key that land on different replicas less than 90 ms apart can resolve backwards ^[1]. Updates further apart resolve correctly. So the exposure tracks how often a single key is written twice in quick succession.

Ninety milliseconds is a small amount of drift to accumulate. The post puts commodity quartz oscillators in the tens of parts per million, where one ppm is one microsecond per second ^[6]. Ten ppm is 36 ms per hour ^[2]. A machine at that rate with no correction is 90 ms out in about two and a half hours ^[3]. On a healthy network the post says NTP holds machines within a few milliseconds of a reference clock ^[7]. Call that five: the example's skew is roughly eighteen times larger ^[4]. Corrections arrive as steps, and after a partition, a VM migration or a long pause the step can go backward ^[8].

The 90 ms is a worked example, and the post does not report how often this happens in production ^[16]. For it to describe your system, three things have to hold. Replicas stamp writes with their own wall clock. The resolver compares those stamps across replicas. Clients update the same key inside the skew window. According to the post, cloud instances are generally harder to keep in tight sync than bare metal unless you opt into the provider's dedicated time service ^[9].

Some of the symptoms in the post are subtractions on one machine: a negative t2 minus t1 after a backward step, a rate limiter that resets mid-window ^[8][5]. The fix for those is a monotonic clock. It only moves forward, and the post recommends time.monotonic(), System.nanoTime() or CLOCK_MONOTONIC for every duration and timeout ^[11]. That change leaves the conflict resolver where it was, because a monotonic clock's zero point is usually machine boot, so its values are meaningless across machines and often across reboots ^[12].

What is left is an ordering question, and Leslie Lamport's 1978 paper answered it with causality: an event happened before another if it came first in the same process, if it is the send of a message the other receives, or if a chain of those links them ^[13]. Where no such chain exists in either direction, the events are concurrent, which the post says "means the system holds no evidence that one came before the other" ^[14]. A resolver handed two concurrent writes has two honest options: keep both and let the application merge them, or carry a clock that encodes causality. The post names Lamport clocks, vector clocks, and the hybrid clocks it says modern databases actually run on ^[15].