# CAP and PACELC Without the Myths — Distributed Systems & Consensus (Raft / Paxos)

Source: https://www.skillbyai.com/en/distributed-consensus/dc-cap-pacelc

> State the CAP theorem precisely, explain what consensus systems choose during a partition, and extend it with PACELC.

## 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.

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

- [ ] Availability vs partition tolerance
- [ ] Durability vs throughput
- [ ] Safety vs liveness
- [x] Latency vs consistency

*Answer:* Latency vs consistency. The 'ELC' part: else (no partition), choose lower latency or stronger consistency.
