CAP Theorem and Database Choice
Fast recall
Quick revision
Core answer
Understanding of fundamental distributed systems trade-offs and how they influence database selection
Repeating 'pick any two' or assigning a permanent CP/AP label without naming the topology, operation, and partition behavior
Define linearizable consistency and availability for the partition period, then explain the exact operation and failure response
Interview-ready guide
Interview answer
CAP applies when a network partition prevents groups of nodes from communicating. During that period, a distributed operation cannot guarantee both linearizable consistency and availability from every non-failing side. To preserve linearizability, some requests may wait or fail because the node cannot prove it has the current state. To preserve availability, both sides may respond even though their histories can diverge and require reconciliation.
This is not a permanent 'pick any two' label and it is not relational versus NoSQL. PostgreSQL replication, MongoDB read and write concerns, Cassandra consistency levels, and DynamoDB table or global-table operations have different partition behavior. For a balance update I may reject work rather than create two accepted histories. For an approximate count I may accept local updates if conflict and repair rules are safe. CAP helps me ask the failure question; the product documentation and operation settings supply the answer.
CAP Theorem and Database Choice
Direct Answer
CAP says that while a network partition is happening, a distributed system cannot guarantee both linearizable consistency and a successful response from every non-failing node. Partition handling is therefore a consistency-versus-availability decision for that failure period. It does not map cleanly to relational versus NoSQL; check the product's topology, operation, and consistency settings.
Code Example
// Conceptual behavior during a network partition — not a database API.
Result handle(Operation op, PartitionState network, Policy policy) {
if (network.cannotReachRequiredReplicas()) {
if (policy.requiresLinearizableResult()) {
return Result.retryableFailure(); // give up CAP availability here
}
Version local = applyLocally(op);
scheduleRepairAndConflictResolution(local);
return Result.accepted(local); // result may not be linearizable
}
return executeWithNormalGuarantees(op);
}
// Real products expose this decision through topology, quorum, read/write
// concern, region, and operation-specific settings. Test the documented case.
Common Mistakes & Pitfalls
- Saying 'pick any two': the C-versus-A conflict appears while a partition prevents the required nodes from communicating.
- Using ACID consistency as CAP consistency: CAP C means linearizability, while ACID Consistency means preserving declared invariants across a transaction.
- Assigning a permanent product label: topology and per-operation settings can change which guarantees are available.
- Calling an error available: CAP availability requires a successful response from every non-failing side, not merely any HTTP or database error.
- Applying CAP to a lone node: the theorem needs a distributed system that can be partitioned into communicating groups.
Check your understanding
Answer these without looking back at the article.
- Is ACID consistency the same as CAP consistency?
- Can a database be both CP and AP in different configurations?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.