CAP starts when communication is partitioned#
“Choose any two” is misleading. In a real distributed system, the network can separate nodes. During that partition, a conflicting operation may have to choose between responding everywhere and preserving a particular strong consistency guarantee.
Use the theorem's terms precisely#
- Consistency
- A specific strong consistency model under CAP, not generic correctness or ACID consistency.
- Availability
- Every request to a non-failing node receives a response under the theorem's model - not a percentage uptime target.
- Partition
- Communication between groups of nodes is lost or disrupted, not data sharding.
One account, two disconnected regions#
If both regions receive a withdrawal, one design rejects or pauses some operations where it cannot safely coordinate. Another accepts in both regions and resolves divergence later. Reads, profile updates, and withdrawals can use different policies; a complete product need not have one universal “CP” or “AP” label.
- “SQL is CA” or “MongoDB is AP” without configuration and operation context.
- “Pick two” as a normal database-selection shortcut.
- Confusing partition tolerance with sharding.
- Confusing CAP consistency with ACID consistency.
- Treating CAP as a complete architecture framework.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which exact link failed?
- Which operations can remain available?
- Which must preserve a stronger guarantee?
- How is divergence detected and repaired?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- CAP Twelve Years LaterEric Brewer, IEEE Computer
Reach this point to mark the lesson as read.