[lucian1900]

Sort of. CAP talks about behaviour during potentially ambiguous failures (network partitions), but most of the systems that call themselves "eventually consistent" also sacrifice consistency under normal operation. Examples are Cassandra, Riak and the original Dynamo.

The main tradeoff is that after writing the values 1, 2, 3 in order, reads could see anything from no value or any one of those three values until the nodes converge.

In a Consistent system, if a read happens after writing and you see a 3, you will never see a 2, 1 or no value on subsequent reads. In the case of a network partition, the system will prefer to not be available than to return reads older than reads that have already been returned.

[pkolaczk]

That's not true for Cassandra. Cassandra allows for stronger consistency, if you only wish to trade some performance for it. If R + W > RF, you are guaranteed to get at least the latest successfully written value. There may be only a temporary inconsistency: during the write some nodes may see the old value, but some other may already see the new value.

[lucian1900]

Sure, if you're willing to trade off latency. As I understand it, if all reads and writes are QUORUM, Cassandra is Consistent (and not Available).

However, I was under the impression that this is not the "default" and I am likely to get performance poorer than distributed systems designed to be Consistent (like HBase).

[jbellis]

Not so: first, writes are always sent to all replicas, so throughput for ONE and QUORUM is identical. The primary difference is that ONE is allowed to complete when more nodes are down.

It's true that QUORUM reads will have half (in a 3-replica system) the throughput as ONE, but with Cassandra reads up to 8x as fast as HBase [1], it still wins handily.

Finally, the reason this is worth making configurable in the first place is that almost all applications do just fine with most operations at ONE.

[1] http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf