CAP is based on three things

Consistency -> there are different types of consistency but in general sense "knowing how valid your data is at the given point in time" en.wikipedia.org/wiki/Consistency_model

Availability -> is it available for writes or reads

Partitioning -> what happens if a network problem is happening

The rule is you can only have 2 out of 3 so you have to decide which is more important and how to compensate for the short comings.

This is not that relevant if you got 1 sql db for example and only 1 core.

you have different transactions models (ACID, BASE) and different Concurrent data-access models (MVVC)

SQL for example has to be on 1 machine and is consistent it will rather be not available than inconsistent.

Mongodb is rather available than consistent, so if you read at the moment the db writes you get an old dataset.

There are different models ... but in the end you can pick what you need.-> is it important to be consistent (financial apps for example), is it important to be available (facebook, streams, push services, ...) and how should they behave if one or more nodes are not available.

For example Kafka in an older version will have a complete data-loss of non distributed data from the root node if the root node gets cut off before it send the write-ack to its children. A partitioning problem that is the consequence of Availability and Partitioning over Consistency. .... and so on.

I hope this helps a little.