So I tried it. I successfully lost data, and reported conflicting/inconsistent data, with a one-line change to your example to-do list. Instead of generating a

So I tried it. I successfully lost data, and reported conflicting/inconsistent data, with a one-line change to your example to-do list. Instead of generating a key that won't conflict, I force it to write to the same key. Yes, this means it's one list item. That's fine, I just need to make this list item inconsistent between two machines. And then I simulate a network partition (virtual machine network disconnect. pull the virtual plug. (EDIT: and repair it!)) This is enough to cause a seconds-long lag before the "okay" case comes through. And a local write during that lag? Completely lost. Two windows. Virtual machine. Game over. This is because your data is overwriting itself, and I don't even care which version I got. I just needed it to not (locally) be the correct one, for any amount of time. It effectively becomes "last write wins" and, well, there's nothing new under the sun. Curiouser and curiouser, the "last write wins" happens in about five seconds. Which happens to be approx. the clock skew. (Called it.) There's some timestamp reliance for sure. It's really easy to break. Caching layer, again, perhaps. Database? Nope. From some people who actually know what they're talking about: http://basho.com/clocks-are-bad-or-welcome-to-distributed-systems/ http://basho.com/clocks-are-bad-or-welcome-to-distributed-sy... (I also got exactly the overwriting "always win" behavior you discussed in the other comment as being a flaw of vector clocks. From where I'm sitting, this smells like a pretty garden-variety vector clock.)