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:
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.
Can you link to the Facebook developer docs for this? I've been playing with their api and haven't seen anything like this, just getting name and uid of friends. Not saying your wrong, just curious.