CAP only speaks during a failure
CAP only describes behaviour during a partition, and partitions are rare, perhaps minutes a year on a decent network. So it says nothing about the other 99.99 percent of the time.
PACELC completes the picture. If there is a Partition, choose Availability or Consistency. Else, choose Latency or Consistency. That else branch runs on every request, all day, which makes it the more useful tool for daily decisions.
The trade you make every other day
The else branch is driven by one thing: replication. Strong consistency needs a write confirmed by other copies before you acknowledge it, and confirmation costs round trips. Copies in the same data centre make that under a millisecond. Copies on another continent make it 100 milliseconds or more, on every write, forever.
Acknowledging after only the local copy commits and writes get fast, but a read arriving at another replica moments later can still see the old value. That is the latency against consistency trade with no partition anywhere in sight.
Systems wear their posture openly once you know to look. DynamoDB is available under partition and serves eventually consistent reads by default, trading consistency for latency and cost. Spanner refuses instead of forking during a partition, and accepts slower cross-region writes to give strict ordering the rest of the time. Cassandra is tunable and leans available. MongoDB with majority writes leans consistent on both branches.
PACELC turns trivia into judgement. Instead of reciting the theorem, say that your system replicates across three regions, so synchronous replication costs about 80 milliseconds per write, and for this workload you will take asynchronous replication with bounded staleness on reads. That sentence shows you know what the trade costs you in milliseconds, not in letters.
Worked example
Leo's team runs a user profile service replicated in Virginia, Frankfurt, and Singapore. With synchronous majority writes, every profile update waits for a transatlantic acknowledgment, about 85 ms, and profile edits feel sluggish worldwide even though the network is perfectly healthy. That is the EL/EC choice in action, no partition involved. They switch to asynchronous replication: writes commit locally in 4 ms, replicas catch up within about a second. The one casualty is read-your-own-writes; Chioma in Lagos edits her bio, her next request routes to Frankfurt, and the old bio flashes back. They patch that specific case by pinning each user's reads to their home region for 10 seconds after a write. Everyday latency won, with a targeted fix for the staleness users would actually notice.