I said we can build a setup that is not tolerant of network partitions and was CA when it was functioning. I didn't say we could build a system that had no network partitions. P is how well it tolerates network partitions, not whether or not it experiences them.

CA means you're not choosing P, which means your system does not have partition tolerance, and that's exactly what ALL does in Cassandra. If any replica is unavailable, the operation fails, and your application suffers.

This is CP: you have chosen to sacrifice availability by making operations fail when replicas cannot be contacted due to a partition. The concept of "partition tolerance" ends up heavily overlapping with the concept of "availability" to the point where trying to make tradeoffs between the two without sacrificing consistency is essentially nonsensical. As put by Coda Hale: "You Can't Sacrifice Partition Tolerence".

http://codahale.com/you-cant-sacrifice-partition-tolerance/

(Sadly, Coda deferred to someone important after writing this article, someone whom I don't think bothered to think through how much more beautiful Coda's explanation of a "partition" is than the AFAICT impossible-to-discern one that supposedly was being used in the original paper :/. I frankly think the final "update" to the article should be ignored. FWIW, in the first "update", it is pointed out that Eric Brewer actually have a very positive shout-out to Coda's article.)

> I frankly think the final "update" to the article should be ignored. Coda updated his post just because he was wrong on his definition of partition. Stonebraker pointed out: "You simply failover to a replica in a transactionally consistent way. Notably, at least Tandem and Vertica have been doing exactly this for years. Therefore, considering a node failure as a partition results in an obviously inappropriate CAP theorem conclusion."

Ah, I see, I misunderstood Availability, I assumed that returning an error would count.