My explanation would be as follows:
Whenever a network partition occurs, you have to make a choice how to handle this situation:
- do you wait for a connection to be re-established with the majority of the nodes, to make sure everyone agrees about the state of the system (This is consistency over availability AKA CP, since the feature is not available until connection with the majority of the network is re-established).
- do you ‘just do something’ and later broadcast the results to the other nodes in the network once connection is re-established? (This is availability over consistency AKA AP, since conflicting changes might happen in different parts (partitions) of the un-connected network, in which case only one of the conflicting changes will ‘win’ in the long run).
There is no way to pick both, although you can decide, on a per-feature basis, which one of these two you’d like to use. (For instance: payments need to be CP, but altering your user profile could be done AP because when such a change is reverted it is not problematic).
Side note: A ‘CA’-system does not mean anything: It is a system that will completely fall over whenever a network partition happens, Both
CP systems are consistent and available as long as there is no network partition anyway.
Interestingly, CRDTs (conflict-free replicated datatypes) are a way to make an ‘AP’ system very close to a CP one, since you make sure from beforehand that it will always be possible to combine data without having to throw anything away (because there will not be a conflict).
Also, there exist a notion of eventual consistency, which is a property many AP systems have, stating that if at some point in the future connection between all parts of the network is re-established, then everyone will agree on a single consistent state again. Many real-word systems work like this; for instance, the Bitcoin blockchain and many similar distributed ledgers are AP with eventual consistency.