Clocks Are Bad, Or, Welcome to the World of Distributed Systems

Is it me, or does the hand waving at the beginning of the article between &quot;write&quot; and &quot;update&quot; smell of bad spin? As a developer I consider both &quot;creates&quot;&#x2F;&quot;updates&quot; as &quot;writes&quot;.<p>&quot;Riak is designed to accomodate (sp) server and network failures without ever losing committed writes, so this led to a quick response from Basho’s engineers.&quot;<p>As such losing a write to me when I read documentation is losing either a create, update or a delete. Any side affecting operation essentially. Anything that needs to write to disk to record a change...

Distributed systems design aside, the core of the problem is that they relied on ntp (as they probably should), and in their case ntp was not working properly.

I don&#x27;t get how clocks are bad this from the article.<p>I get that syncing clocks across systems is hard and when it goes awry, unintended consequences are incurred.

Decades ago albert einstein introduced the general theory of relativity, which is already telling us that timestamps are bad for synchronisation.

Dumb question: What breaks with the following approach?<p>1) set last_write_wins=true (so all updates, always apply, as described in the article)<p>2) avoid the &quot;partition&#x2F;rejoin may cause old values to stomp on new&quot; issue by having &quot;rejoin detection&quot; which refuses to rejoin if clocks are &quot;too out of sync&quot;

How do other distributed databases handle this?

I can&#x27;t scroll down.

How would you get around the unreliability of clocks in VMs? Seems like deploying Riak in the cloud could be problematic.

Mars design. Assume one server is on Mars, with associated time dilation on it&#x27;s clocks and latency.