Also to be taken with its sister post: http://basho.com/why-vector-clocks-are-hard/

If anyone from basho is here, the link[0] at the end of this article leads to a 404. I guess it might've been moved to this[1].

[0]: http://basho.com/technology/why-use-riak/ [1]: http://docs.basho.com/riak/latest/theory/why-riak/

OK, in that case we are ready for the next level: Interval Tree Clocks ;P.

https://code.google.com/p/itclocks/

Hash histories are more light when you have an unbounded number of replicas.

https://oceanstore.cs.berkeley.edu/publications/papers/pdf/h...

Interesting but vector clocks are still kind of unwieldy.

The example from the article is people trying to figure out when the group should all go to dinner; no one actually cares the end result, the only that is needed is agreement. This isn't free in many real-world problems. Knowing that you have correctly stored the final value is sometimes required. Vector clocks only lets you fix the problem after it has occurred.

Dave has to sort out the conflict, but wasn't that the exact same person who couldn't be reached to sort out the initial conflict?

Dave was available at times 1, 2, and 3

Dave is not available to resolve the conflict at time 4

Dave sorted out a conflict at time 3 in all versions of the the story. The problem is that nobody else knew which message was from time 2, and which was from time 3. Vector clocks fix that problem.

Now in this particular case you could use a normal clock, but in more complicated scenarios that can lead to mistakes where vector clocks still work.

+1 Good read, and explained clearly. Helped me for my distributed systems class last semester.

That sort of mechanism is useful for database systems which have to decide in what order to write out blocks to keep the database consistent. That requires partial ordering, but not total ordering.