2026-06-07
CAP theorem says a distributed data store can only guarantee two of three properties: Consistency (every read sees the latest write), Availability (every request gets a non-error response), and Partition tolerance (the system keeps working when network links drop messages). The catch most engineers miss: partitions will happen. Cables get cut, switches die, cloud zones isolate. So the real choice is between CP and AP — never CA.
When a partition occurs, your system has two options:
Real-world example: You're building a shopping cart. A user in us-east adds an item; the partition splits us-east from us-west right as replication kicks in. CP choice (etcd-style): the write fails, the user sees "try again." AP choice (DynamoDB-style): the write succeeds locally, replicates after the partition heals, and if the user added items from both sides, you merge the carts (Amazon famously chose "add" semantics for shopping carts — you'd rather over-include than lose a sale). Now compare to a bank ledger: never AP. A double-spend is worse than an error message.
Rule of thumb: If the cost of stale or conflicting data exceeds the cost of an error, pick CP. If the cost of an error exceeds the cost of reconciliation, pick AP. Money, inventory counts, and unique-constraint enforcement → CP. Likes, view counts, session data, shopping carts → AP.
Two common misunderstandings to avoid:
PACELC extends CAP usefully: during a Partition, choose A or C; Else, during normal operation, choose between Latency and Consistency. Most "AP" systems are really PA/EL — they trade consistency for latency even when no partition exists, because synchronous replication is slow.
