To nail down some definitions: C.A.P. = Consistency, Availability, Partition tolerance.
If their goal is hardline 'C,' that means (pedantically) if a partition is detected, the database reports back to the application "database partition exists. denying all reads and writes until resolved."
If you can't tolerate a partition but still want to claim 'A' (where "tolerating" requires merging structured data cleverly with CRDT-like things ("eventually") or last write wins (or even better: random write wins (which is basically a traditional RDBMS approach))), then they can be read-avail and maybe report metadata back to the client you're in read-only mode due to partition crappage and data isn't going to update until partition crappage resolves itself. Look! It's available! I can read from it!
(notably: in Amazon's original Dynamo case, write availability was more important than read availability, which is where ESCAPE comes in ("Eventually Somewhat Consistently Available Partition tolerant Engine"))
If their goal is hardline 'C,' that means (pedantically) if a partition is detected, the database reports back to the application "database partition exists. denying all reads and writes until resolved."
If you can't tolerate a partition but still want to claim 'A' (where "tolerating" requires merging structured data cleverly with CRDT-like things ("eventually") or last write wins (or even better: random write wins (which is basically a traditional RDBMS approach))), then they can be read-avail and maybe report metadata back to the client you're in read-only mode due to partition crappage and data isn't going to update until partition crappage resolves itself. Look! It's available! I can read from it!
(notably: in Amazon's original Dynamo case, write availability was more important than read availability, which is where ESCAPE comes in ("Eventually Somewhat Consistently Available Partition tolerant Engine"))