Distributed Systems
CAP in practice: multiple-choice review
Crux Multiple-choice synthesis across the CAP unit — formal C/A definitions, the CP/AP partition choice, PACELC's healthy-state tradeoff, logical partitions, and AP conflict resolution.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a decision you make in a real on-call incident — not an acronym to recite, but a tradeoff to defend while the network is silent.
Goal
Confirm you can connect the formal CAP definitions, the binary CP/AP partition choice, PACELC’s healthy-state latency tradeoff, and the production failure modes — the synthesis the lesson built toward.
Quiz
Completed
A vendor markets its database as 'always available, fully consistent, partition tolerant — CAP-complete.' Why is this claim incoherent under the Gilbert-Lynch proof?
Heads-up Raft is CP: when a partition isolates the leader from the majority, the minority rejects reads and writes to preserve linearizability. It buys consistency by giving up availability on the isolated side, not by escaping the theorem.
Heads-up Partitions are physically inevitable — cut fibers, BGP flaps, hypervisor pauses. P is mandatory, which is exactly why C-vs-A becomes a forced choice rather than a free lunch.
Heads-up Uptime is an operational SLA, not the per-request liveness property CAP defines. A 'five nines' cluster can still be formally CP and reject requests during a partition.
Quiz
Completed
A 5-node etcd cluster splits 2-3 by a partition. The 2-node side rejects all reads and writes with errors; the 3-node side keeps serving. How do you classify this behaviour?
Heads-up Availability in CAP requires every non-failing node to respond successfully. The 2-node minority returns errors, so the system as a whole sacrifices A — this is CP, not AP.
Heads-up A minority that kept serving writes would split-brain and break linearizability. Refusing is the correct, intended CP behaviour for a quorum system like etcd.
Heads-up No-data-loss is a durability property, unrelated to the CAP A/C axis. The minority being unable to respond successfully is precisely what makes this CP.
Quiz
Completed
Two engineers both pick 'CP'. One says reads in another region now add 80 ms; the other insists CP changes nothing when the network is healthy. Who is right, and why?
Heads-up PACELC's whole point is that strong consistency costs latency even when healthy: a linearizable read/write must coordinate synchronously across replicas, adding RTT. PC/EC systems pay this constantly.
Heads-up Cross-region coordination latency is network RTT between replicas, not disk. Synchronous quorum acknowledgement across datacenters is the dominant cost for EC systems.
Heads-up The 80 ms is the inherent cost of synchronous coordination (EC), not a misconfiguration. PACELC predicts exactly this latency-for-consistency trade in the healthy 'Else' state.
Quiz
Completed
Classify Google Spanner and Amazon DynamoDB (default) on the PACELC axis, and say what that predicts about each.
Heads-up Being cloud-hosted says nothing about the CAP/PACELC stance. Spanner deliberately chooses consistency (PC/EC) and accepts the coordination latency; only DynamoDB defaults to PA/EL.
Heads-up This is reversed. Spanner blocks rather than serve stale data (PC/EC); DynamoDB stays available and eventually consistent by default (PA/EL).
Heads-up They predict concrete behaviour: PC/EC rejects writes under partition and adds RTT when healthy; PA/EL keeps serving and can return stale reads. The labels map to observable decisions.
Quiz
Completed
A healthy CP leader survives the network fine but suffers a 10-second stop-the-world GC pause; peers immediately trigger a leader re-election. What is the root cause class?
Heads-up Raft uses logical terms and sequence numbers, not wall-clock synchronization. The trigger is missed heartbeats from the paused node, not clock skew.
Heads-up A GC pause stalls application threads; it never touches the NIC or OS network stack. The node is reachable but unresponsive — a logical partition.
Heads-up It is disruptive: the cluster loses its leader, blocks writes during the election, and the old leader's in-flight work is wasted. This is why pre-vote and tuned timeouts matter.
Quiz
Completed
You run an AP store (Cassandra/DynamoDB style) and resolve concurrent writes with Last-Write-Wins on wall-clock timestamps. What is the hidden failure mode?
Heads-up 'Most recent' is decided by clock timestamps, and clocks drift. A genuinely-later write on a lagging node loses to an earlier write with a higher timestamp — LWW silently discards real data.
Heads-up It fails on ordinary concurrent writes across partitions with skewed clocks — no datacenter loss required. This is the everyday AP conflict-resolution tax.
Heads-up You can stay AP and fix conflict resolution with CRDTs or vector clocks, which merge or order writes without a single wall-clock winner. Switching to CP is one option, not the only one.
Recap
The through-line: P is not a choice, so a partition forces the binary CP-vs-AP decision — block/error to keep linearizability, or stay responsive and serve divergence. PACELC extends this to the healthy state, where strong consistency still costs latency. The production traps — vendor ‘CAP-complete’ claims, logical partitions from GC pauses, and LWW silently dropping writes under clock skew — all resolve back to the same discipline: use the formal definitions, classify your system honestly on PC/EC vs PA/EL, and tune to the workload’s real correctness needs.