The CAP theorem & PACELC

R2 is stranded on the wrong side of the partition. Toggle between the two choices and watch: one refuses to respond at all; the other answers immediately with whatever it has — even knowing it might be stale.

During a network partition, there is no third option:

1. CP

   Refuse to answer unless you can prove you have the latest write. Cut off, you can't prove it — so you block or error. Consistency is preserved; availability is not.

2. AP

   Always answer with whatever you have locally. Availability is preserved; the answer might be stale.

PACELC extends this past the partition case: even with no partition (the "Else" branch), a system still trades Latency against Consistency — confirming a write with every replica synchronously raises consistency but costs latency, and vice versa.

• P — the partition-time choice: Consistency or Availability.
• E — the normal-time ("Else") choice: Consistency or Latency.

Toggle both axes independently and watch pacelcLabel produce one of the four canonical two-letter-pair labels — then see whether it matches any of the three example systems below.

1. CP, applied to R2

   resolveDuringPartition(STALE_PARTITION_SCENARIO, "CP") returns responds = false, value = null, consistent = true. No answer, but no risk either.

2. AP, applied to R2

   resolveDuringPartition(STALE_PARTITION_SCENARIO, "AP") returns responds = true, value = 1, consistent = false. An answer, but a stale one — R2's local value hasn't caught up.

3. Classifying real systems

   • Dynamo/Cassandra: chooses Availability during a partition ($P{=}A$) and Latency otherwise ($E{=}L$) → PA/EL
   • A majority-write MongoDB: chooses Consistency during a partition ($P{=}C$) but Latency otherwise ($E{=}L$) → PC/EL
   • A fully-synchronous SQL cluster: chooses Consistency both times ($P{=}C$, $E{=}C$) → PC/EC