You Can't Sacrifice Partition Tolerance

I think the author, like many recently exposed to the CAP theorem, is confused about the meaning of partition tolerance, leading to ridiculous conclusions. Partition tolerance does not mean your distributed system can't be consistent and available because your network dropped one packet, or one node failed. What would be the point of such a definition? Instead, the CAP theorem implies that while the network is partitioned, consistency or availability must be sacrificed. In the case of the dropped packet…

You can make partition tolerance arbitrarily low in practice with enough work and resources. But you can never eliminate it. Note it is not just network failures here, because a dead machine and an inaccessible machine are both unavailable. So in theory you have to choose in the event of P do you sacrifice A or C. That's CAP in a nutshell. You have to plan for P so choose your failure mode in that case. And this is where…

Stonebraker says real systems can obviously achieve "CA" when one node is partitioned off. But he slyly switched out the theorem's definition of "available" for a more colloquial definition. The CAP theorem definition requires every live node, including the lone segregated guy, to respond to clients. Real "CA" systems don't do that--they're "available" because the non-partitioned nodes are still responding.

Maybe I'm missing something, but it seems like this is basically just glossing over this part: > Some systems cannot be partitioned. Single-node systems (e.g., a monolithic Oracle server with no replication) are incapable of experiencing a network partition. But practically speaking these are rare; I'm not sure how the writer came to the conclusion that these systems are rare. The website I'm working on now has a single monolithic Postgres server, and the majority of systems I've worked on…