CAP and PACELC Without the Myths

The precise version of CAP

The CAP theorem (proved by Gilbert and Lynch) says: when a network partition happens, a system cannot be both linearizable (C) and available (A), where available means every non-failed node answers every request. The popular phrase 'pick two of three' is misleading, because partitions are not optional; you choose how to behave when one occurs. CP systems, such as a Raft or Paxos cluster serving linearizable operations, refuse requests on the minority side of a partition so the majority side can stay consistent. AP systems keep answering on both sides and reconcile later. PACELC adds the everyday case: if Partitioned, choose A or C; Else, choose Latency or Consistency. Even with a healthy network, a linearizable write must wait for a quorum round trip, while a weaker model can answer locally.

Two bank branches lose their link

If the Pune and Delhi branches of a bank cannot reach each other, either both stop withdrawals from a shared account until the link returns (consistent, not available), or both allow withdrawals and risk an overdraft that must be fixed later (available, not consistent).

Minority side behaviour

In a 5-node Raft cluster split 2 | 3, the old leader on the 2-node side cannot commit anything because it cannot reach a majority. Clients connected to it see timeouts or errors, not stale successes. That is CP in action.

Quick check: Under PACELC, what trade-off does a system face when there is NO partition?

• Availability vs partition tolerance
• Durability vs throughput
• Safety vs liveness
• Latency vs consistency