4.4.25 · D5Databases
Question bank — CAP theorem — consistency, availability, partition tolerance
True or false — justify
Each line: decide true/false, then give the reason. Reveal shows the reasoning that actually matters.
A distributed system can be built to be C, A, and P all at once during a partition.
False — a node cut off from a write cannot both answer (A) and return that unseen write (C); the two demands are logically contradictory for at least one node.
"CP or AP" is a choice you make only when a partition is happening.
True — with a healthy network you serve both C and A; the forced pick between them appears only during a partition.
You can design a system to simply "not tolerate partitions" and thereby avoid the trade-off.
False — partitions are caused by cable cuts, GC pauses, and packet loss, which don't ask permission; dropping P just means the system breaks (loses C or A anyway) when one occurs.
A single-node (non-distributed) database has to make a CAP trade-off.
False — with one node there are no inter-node messages to partition, so C and A never conflict; CAP only bites once data is replicated across nodes.
The "C" in CAP is the same guarantee as the "C" in ACID.
False — CAP-C is linearizability (all replicas agree on the latest value); ACID-C is preserving transaction invariants (constraints, foreign keys) inside one database.
An AP system is "eventually consistent," so it never returns wrong data.
False — during and shortly after a partition it can return stale/conflicting data; "eventual" only promises replicas converge later, not that every read is correct now. See Eventual Consistency.
A CP system that rejects requests during a partition has "failed."
False — rejecting/erroring is the correct, designed behaviour of CP; it sacrifices A on purpose to guarantee no stale read. That is working as intended, not a bug.
If you never see partitions in production, CAP is irrelevant to your design.
False — PACELC shows that even with no partition (the "Else" branch) you still trade Latency vs Consistency every single request, so the tension is live daily.
Availability in CAP means "the system has high uptime / good SLA."
False — CAP-A is a strict logical property: every request to a non-failing node returns a non-error response. A 99.99% uptime system that ever errors a live node is not "A" in the formal sense.
Choosing AP means you must permanently give up consistency.
False — you give up C only during the partition; once the link heals, replicas reconcile (e.g. merge, last-write-wins) and consistency is restored.
Spot the error
Each statement contains a flaw. Name it in one sentence.
"Our database is CA — consistent and available — so we don't worry about partitions."
A "CA" system is one that gives up P, meaning it simply stops being correct-and-available the moment a real network partition hits — CA is not achievable for a genuinely distributed system.
"Cassandra is AP, so a read is always guaranteed to be the newest write."
AP sacrifices C during partitions; an AP read is guaranteed to be a response, not the newest value — freshness depends on quorum settings, not the AP label.
"We use majority-quorum writes, so we are simultaneously fully C and fully A during a partition."
If a partition leaves the minority side unable to reach a majority, that side must reject writes/reads to stay consistent — so it loses A; quorums buy C at the cost of A on the losing side. See Replication and Quorums.
"During a partition we picked A, so all our nodes now serve identical data."
Picking A means each side answers from its own possibly-diverged copy; the two sides can serve different values until the partition heals and they reconcile.
"CAP proves you can only ever pick 2 of the 3 properties."
The "2 of 3" framing is the classic trap — P is not optional in a distributed system, so the real theorem is "during a partition, pick C or A."
"PACELC replaces CAP; you only need to remember PACELC."
PACELC extends CAP by adding the Else/Latency-vs-Consistency case; it contains CAP as its partition branch rather than replacing it. See PACELC theorem.
"Consensus algorithms like Raft give you C, A, and P together — they beat the theorem."
Raft/Paxos are CP: a partitioned minority cannot elect a leader and so stops serving (loses A) to preserve C — they obey CAP, not beat it.
Why questions
Answer the reason, not just the fact.
Why can a partitioned node not return the latest write?
The partition physically prevents it from receiving that write, so the node has no information about the new value and cannot fabricate it.
Why is P treated as non-optional while C and A are treated as choices?
Partitions are imposed by the physical network (hardware faults, delays) and cannot be prevented by design, whereas C and A are behaviours the software chooses when a partition strikes.
Why does a bank balance favour CP over AP?
A stale balance could let two ATMs both approve a withdrawal (double-spend, real money lost), so correctness (C) must beat uptime (A); the ATM refuses rather than risk overdraw.
Why does a shopping cart favour AP over CP?
A momentarily wrong cart is a minor annoyance, but an unavailable "Add to Cart" loses a sale instantly — so answering (A) is worth more than momentary correctness (C).
Why does the C-vs-latency trade-off exist even with a perfectly healthy network?
Waiting for all replicas to acknowledge a write (for strong C) takes real round-trip time, so guaranteeing freshness always costs latency — the PACELC "Else" branch.
Why is the two-node write/read scenario a proof rather than a story?
It shows a specific node () that provably lacks the write information, so no implementation can make it both answer and be correct — a logical impossibility, not a mere example.
Why does an AP cart merge items by union rather than picking one side?
A commutative merge (union) loses no write regardless of order, so both concurrent additions survive when the partition heals — a last-write-wins pick could silently drop a customer's item.
Edge cases
The boundary scenarios the definitions must still cover.
If the network is perfectly healthy and stays healthy, what does CAP force you to give up?
Nothing under CAP — with no partition you can serve both C and A; only PACELC adds the further Latency-vs-Consistency choice here.
A node has crashed (not partitioned) — does CAP's Availability clause apply to it?
No — CAP-A only requires non-failing nodes to respond; a crashed node is failing, so it is excused from the availability guarantee.
A CP system during a partition returns an error to every request. Is it still "consistent"?
Yes — returning an error (rather than stale data) is allowed by the C definition ("most recent write or an error"); silence/error keeps correctness intact.
Both partitioned sides accept writes to the same key independently — what property is at stake at heal time?
Consistency: you now have a write conflict that reconciliation must resolve (merge, LWW, or vector clocks); until resolved the replicas disagree. See Eventual Consistency.
The partition heals after an AP system served stale reads — is consistency automatically restored?
Not instantly — replicas must propagate and reconcile the diverged writes first; consistency returns only after convergence completes, which is why it's called eventual.
A partition splits the cluster so that neither side has a majority. What happens in a quorum-based CP system?
Both sides fail to reach quorum, so both refuse writes — total loss of availability, but consistency is preserved because no un-agreed value is ever committed. See Replication and Quorums.
A single client talks to a single reachable replica during a partition — can it perceive a violation?
If the system is CP and that replica can't reach quorum, the client sees rejection/error (A lost); if AP, the client gets an answer that may be stale (C lost) — the trade-off is visible even to one client.
Connections
- Distributed Systems
- ACID vs BASE
- Eventual Consistency
- Replication and Quorums
- PACELC theorem
- Consensus — Paxos & Raft
- NoSQL Databases