How does RavenDB achieves consistency, availability, and partition tolerance?

Question

According to CAP theorem it is impossible for a distributed computer system to simultaneously provide consistency, availability, and partition tolerance.

Reading about RavenDB it looks like this database supports ACID transactions and sharding at the same time. How does RavenDB achieves that?

Answer 1

To clarify things upfront:
by default all writes in a RavenDB session between calls to .SaveChanges() are all-or-none. If one operations fails for whatever reason, then all changes in the current session/since the last save will be discarded. This feature, in combination with optimistic concurrency turned on, is very powerful. If you need longer transaction, there is support for System.Transaction as well, and that works as expected.

In regards to sharding:
There is no true support for distributed transactions in a sharded setup. However, due to the locality of reference documents in a good sharding strategy, you can have transactional writes on each of your stores. They simply work the same as if there weren't any shards at all.

Answer 2

CouchDB is in the same boat: They are "ACID" (when viewed from a single node), but not Consistent (when viewed from CAP). Database terminology can be confusing.

P.S. The "Availability" you linked to is not the A in CAP. The A in CAP stands for "All nodes able to accept queries". For example, during a partition, PAXOS will only answer queries in the majority partition, but the minority partition will refuse to answer queries.

But viewed from an availability standpoint, it's got better availability than the system going down. If the system needs Consistency, then this is the highest availability you can achieve.