Traditionally, the CAP theorem has generally been summarized as “Consistency[[Consistency|]], Availability[[Availability (uptime)|]], Partition tolerance*: choose 2 of 3.” Kleppman (p. 523) argues that this is “unhelpful,” as the theorem actually has a narrower scope. Consistency in the CAP theorem is defined as linearizability; the only possible fault is network partition.
Instead, he gives a narrower explanation (still p. 523; emphasis his and links mine):
If your application requires linearizability, and some replicas are disconnected from the other replicas due to a network problem, then some replicas cannot process requests while they are disconnected: they must either wait until the network problem is fixed, or return an error (either way, they become unavailable).
If your application does not require linearizability, then it can be written in a way that each replica can process requests independently, even if it is disconnected from other replicas (e.g., multi-leader). In this case, the application can remain available in the face of a network problem, but its behavior is not linearizable.
Thus, applications that don’t require linearizability can be more tolerant of network problems. This insight is popularly known as the CAP theorem.
Possible combinations
CP: Every replica reports the same values, even if there is a network fault. You need to prevent all action in the face of a network fault to make this promise, so you can’t be available. See synchronous replication.
AP: You can continue to use the system even when the network is partitioned. Think of offline mode for connected mobile apps; they can get totally out of sync (inconsistent). Multi-leader replication and leaderless replication can work here.
CA: You can continue to use the system when nodes fail, and you can count on consistent responses from any remaining node, but the system doesn’t work when the network is partitioned.