Why partition tolerance isn't optional — the real choice is CP vs AP — CP and AP examples, and the PACELC extension covering the latency/consistency trade even without a partition.
Published September 23, 2026
The theorem: during an actual network partition, a distributed system can only fully guarantee two of these three — and since partition tolerance is effectively mandatory (see below), the real, practical choice in the presence of a partition is Consistency or Availability, not all three simultaneously.
During a partition, a CP system rejects requests (or blocks) on the minority side of the partition rather than risk serving stale/inconsistent data — traditional RDBMS clusters with synchronous replication, and systems like ZooKeeper/etcd (which explicitly prioritize consistency for coordination use cases), are CP: correctness over uptime when forced to choose.
During a partition, an AP system keeps serving requests on both sides of the partition, accepting that some responses may be stale or that concurrent writes on different sides might later need reconciliation (see Eventual Consistency Design's conflict-resolution strategies) — DynamoDB and Cassandra are classic AP examples: they'd rather answer with possibly-stale data than return an error.
A system that chooses to NOT tolerate partitions is choosing to fail (become entirely unavailable) the moment a partition occurs — which is rarely an acceptable choice for any real distributed system running across multiple nodes/data centers, since network partitions are a normal, expected operating condition at scale, not a rare edge case to design around. This is why CAP is more accurately framed as "CP vs AP," not "pick any 2 of 3" — partition tolerance is a practical requirement for any genuinely distributed system, and the real decision is what happens to consistency vs availability specifically during that (inevitable, eventually-occurring) partition.
CAP only describes behavior during a partition ("P"). PACELC extends the framework: Partition — if a partition occurs, choose Availability or Consistency (exactly CAP's choice); Else (no partition, normal operation) — choose Latency or Consistency. Even when everything is healthy and no partition exists, a system replicating data across nodes still faces a choice: wait for all replicas to acknowledge a write before confirming it (lower latency sacrificed for stronger consistency), or confirm immediately and replicate asynchronously (lower latency, but a read might briefly see stale data on a lagging replica — see Sharding vs Partitioning vs Replication's replication-lag discussion). PACELC is the more complete framework precisely because it captures that this latency-vs-consistency tension exists at all times, not only during the comparatively rare partition scenario CAP alone addresses.
Q: Can a single system be CP for some operations and AP for others? A: Yes, and this is common in practice — a system might use strong consistency (CP behavior) for critical operations like payment processing while accepting eventual consistency (AP behavior) for less critical data like view counts or recommendation caches, matching the consistency model to each specific operation's actual business requirement rather than applying one uniform choice system-wide.
Q: Is MongoDB (this platform's own database) CP or AP? A: Configurable, depending on write/read concern settings — MongoDB's default replica-set behavior with majority write concern leans CP (a write isn't acknowledged until a majority of replicas confirm it, prioritizing consistency), but it can be tuned toward AP-leaning behavior with weaker write/read concerns, which is exactly why 'is database X CP or AP' often has a more nuanced answer than a single fixed label.
Q: How does PACELC's 'Else' branch relate to the read replica trade-offs already covered in Sharding vs Partitioning vs Replication? A: It's the same underlying tension stated in CAP/PACELC's vocabulary — a synchronous replica write (waiting for replica acknowledgment) trades latency for consistency; an asynchronous replica write (the common read-replica pattern) trades consistency (replication lag) for latency, exactly PACELC's 'Else: Latency or Consistency' choice applied to that specific mechanism.
Q: Why do systems like ZooKeeper/etcd specifically need to be CP, given their use case? A: They're typically used for distributed coordination (leader election, distributed locks — see Design: Distributed Lock Service) where serving STALE data would be actively dangerous (two nodes both believing they're the leader because they saw inconsistent state) — for this specific use case, unavailability during a partition is a far safer failure mode than availability with potentially-wrong data, which is exactly why CP is the correct choice for coordination systems specifically, even though AP is right for many other use cases.
