Q:

Distributed Erlang and the CAP theorem

By the CAP theorem, it is impossible for a distributed Erlang system to simultaneously provide all three of the following guarantees:

Consistency (all Erlang runtimes, or nodes, see the same data at the same time)
Availability (node failures do not prevent survivors from continuing to operate)
Partition Tolerance (the system continues to operate despite arbitrary message loss)

A distributed Erlang system can support zero, one, or two of the guarantees.
Using Erlang and OTP, how can each guarantee be implemented? Most distributed Erlang applications make the practical choice for higher levels of  A and P, and settle for "eventual consistency". It seems Erlang itself was designed to support distributed (P), fault-tolerant (A), soft-real-time, non-stop applications.
The programming language (Erlang), run-time system (ERTS), and set of libraries (OTP) are designed for building distributed fault-tolerant applications; how do I do the three things that define distributed fault-tolerant applications?

A:

EDITED for clarity
It depends on the design of your application and not the platform in which you implement it.  You could implement any 2 of the guarantees, with just about any language or platform combination.

A:

A really good example I found is Riak, a distributed key-value store based on Amazon's Dynamo and built using Erlang and OTP. The tunable CAP controls let you dynamically "choose" your levels of consistency and availability; it chooses to focus on the A and P of CAP, which makes it eventually consistent. Riak is open-source, and there are a number of good articles online regarding its implementation.
Another good example is Dynomite, PowerSet's Dynamo-clone-in-Erlang. Although the project has been dead for a while, it serves as a useful functional design document on how to build a Dynamo clone.
These two projects are themselves based on Amazon's Dynamo, an incrementally scalable, highly-available key-value storage system. The technology is designed to give its users the ability to trade-off cost, consistency, durability and performance, while maintaining high-availability. The paper is a good read.

