I do not use CAP as a slogan. I use it as a production question: when the network splits, should this path keep accepting work or protect one version of truth?
The tradeoff appears during the partition
When I talk about "The tradeoff appears during the partition", I am really asking what CAP Theorem does when a message is late, duplicated, or missing.
Before a partition, a system can be both available and consistent enough for its design. The tension appears when messages cannot cross a network boundary. At that point, the system needs a rule that operators and product teams understand.
Checkout example
I use "Checkout example" to keep CAP Theorem grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
Two regions both accept a balance transfer while the link between regions is down. If both regions can write independently, reconciliation may find that the account spent the same money twice.
Partition handling code
When I show "Partition handling code", I want the code in CAP Theorem to reveal the production decision, not just the syntax.
During a partition, make the risky write rule explicit:
Response handle(Request request, boolean partitioned) {
if (partitioned && request.isRiskyWrite()) {
return Response.reject("Write paused until replicas agree");
}
return request.isRead() ? serveFromLocalReplica(request) : commit(request);
}The branch makes the CAP tradeoff explicit: reads can continue locally during a partition, but risky writes stop until replicas can agree again.
Sequence diagram: the partition choice
CAP is not asking what you prefer on a normal day. It asks what the system does when the link is broken.
The tradeoff to name
- Name which data must stay strongly consistent.
- Name which workflows can accept delayed convergence.
- Document the user visible behavior during a partition.