The mechanism. CAP says that when the network partitions, a replicated system must either refuse to answer (preserving consistency) or answer from possibly-stale state (preserving availability). It is a statement about a specific failure mode, not a ranking of databases.

Why the popular version is wrong. "We picked AP" is usually meaningless, because partitions are rare and the interesting tradeoff is the one you make all the time: latency versus staleness. That is PACELC — Partition: A or C, Else Latency or Consistency. Most systems that call themselves AP are really choosing L over C on every single read, partition or not.

Where it bites. Teams read CAP as permission to skip reasoning about consistency entirely. Then a user updates their profile, a read hits a lagging replica, the UI shows the old value, and the user clicks save again on stale data. No partition occurred; the problem was replica lag, which CAP never mentioned.

Takeaway. Ask the real question: what does a read return when the last write went to another replica, and what does the user do with that answer?