More than that. Individual operations in a system could be AP and others CP. If you have something like dynamic quorum sizes, making quorums a majority would work towards some form of CP, while making it smaller than a majority could work towards AP constraints.
There are of course more mechanisms to consider when positioning yourself on the spectrum, but nothing would keep you from requiring CP for operations that have to do with subscriptions, and AP for operations that show how many people are online on a website, for example.
Then you have to consider 'refinements' over cap such as PACELC, where you can decide to switch modes depending on cluster health. For example, you could decide that when there is a (P)artition, you are (A)vailable, (E)lse, you are (C)onsistent. Nothing also stops you from providing, if you want extremely low latency, no consistency at all. For a cache, choosing latency (which would be PAEL, where L stands for Latency) would make sense.
CAP is just the very basic set of rules to consider when going distributed.
There are of course more mechanisms to consider when positioning yourself on the spectrum, but nothing would keep you from requiring CP for operations that have to do with subscriptions, and AP for operations that show how many people are online on a website, for example.
Then you have to consider 'refinements' over cap such as PACELC, where you can decide to switch modes depending on cluster health. For example, you could decide that when there is a (P)artition, you are (A)vailable, (E)lse, you are (C)onsistent. Nothing also stops you from providing, if you want extremely low latency, no consistency at all. For a cache, choosing latency (which would be PAEL, where L stands for Latency) would make sense.
CAP is just the very basic set of rules to consider when going distributed.