CAP is a simple and obvious principle: If you have a partition, meaning you cannot always meet your read/write quorums, you can choose: - availability: always

CAP is a simple and obvious principle: If you have a partition, meaning you cannot always meet your read/write quorums, you can choose: - availability: always accept writes, but reads in other partitions might not see them so there's no consistency. - consistency: writes fail/block until the partition is resolved, so there's no availability. Clearly, parts of your data that are not affected by a partition might still be consistent and available. The point is, in classical database systems 100% of transactions are consistent. In distributed databases this is only possible if you sacrifice availability some of the time, or alternatively you can sacrifice consistency some of the time. The author of this paper is suggesting a more elaborate theory that involves network delay, which is great, though criticising what is effectively a mathematical truth seems strange.