HN user

reiddraper

137 karma

I work for http://basho.com https://github.com/reiddraper/

gmail is reiddraper

Posts10
Comments14
View on HN

There are a several ways to approach this. The simplest is to just take last-write-wins, which is the only option some distributed databases give you. For cases where this isn't ideal, you resolve write-conflicts in a couple ways.

One way is to write domain-specific logic that knows how to resolve your values. For example, your models might have some state that only happen-after another state, so conflicts of this nature resolve to the 'later' state.

Another approach is to use data-structures or a library designed for this, like CRDTs. Some resources below:

A comprehensive study of Convergent and Commutative Replicated Data Types http://hal.archives-ouvertes.fr/inria-00555588/

https://github.com/reiddraper/knockbox https://github.com/aphyr/meangirls https://github.com/ericmoritz/crdt https://github.com/mochi/statebox

Riak 1.0 15 years ago

The replication in the Enterprise version is replication between entirely different clusters. The ring replication you talk about is definitely open source.

Another thought. If availability is your goal, with the trend toward 'operations as code', I think a small development team can build a system on top of AWS that can automatically respond to arbitrary node/resource/data-center failure. Netflix seems to do this to an extent, with their Chaos Monkey.

That being said, there are situations where you may truly need single-node performance that isn't available on AWS.

Actually, that's not what he said. Here's the full quote: "I’m at the end of the first chapter that explains how Erlang’s concurrency features work"

A quick look shows that it's the sixth chapter. Either way, he's clear about this disclaimer, and his post was enough to peak my interest in this specific book.

For you, first impressions _do_ seem to mean much.