CAP and PACELC: When to Cite Which

Definition

CAP (Brewer): In the presence of a partition (network split), you cannot have both strong consistency (C) and full availability (A) in the usual asynchronous network model; you pick a tradeoff during that partition. PACELC extends this: if partitioned (P) choose A vs C; else (E, normal operation) choose latency (L) vs consistency (C).

Important nuance: CAP is about behavior during partitions, not "pick two forever" in steady state. Many systems are AP under partition (stay available, reconcile later) but CP in design for certain paths (e.g., leadership with quorum).

Why it matters in interviews

Interviewers use CAP/PACELC to probe whether you align choices with failure modes. Saying "we'll use NoSQL so we're scalable" without discussing consistency vs latency under load is shallow. Citing PACELC signals you know latency–consistency tension in the happy path—critical for globally distributed systems and caching strategies.

Tradeoffs

CAP focus — Good when discussing split brain, quorum, Kafka ISR, MongoDB/HBase behavior during netsplits. Misused when applied to single-datacenter CRUD without partitions.
PACELC focus — Good when discussing read-your-writes, replica lag, async replication, Dynamo-style SLAs: even without a partition, strong consistency often costs latency (extra round trips).
Over-indexing on CAP alone can miss eventual consistency tradeoffs that dominate daily operations (not just disasters).

When to cite CAP — Multi-region, leader election, quorum reads/writes, explicit partition tolerance stories.

When to cite PACELC — "Under normal load, do we read from the leader or a replica?" "Is read-after-write global or session-scoped?"

Concrete examples

Dynamo / Cassandra-style — Often AP under partition; PACELC: in normal operation you choose L (fast local read) vs C (read repair, quorum read).
ZooKeeper / etcd — CP flavor: prefer consistency and accept unavailability of minority partition; CAP applies when the cluster cannot form a majority.
Single-region Postgres with streaming replica — No active partition under normal assumptions; PACELC explains why async replica gives lower read latency but stale reads; CAP enters if network splits the primary from replicas and clients.

How to say it in 30 seconds

"CAP is really about network partitions: you often trade linearizable consistency against answering every request. PACELC adds the everyday case: without a partition, you still trade latency vs consistency—for example reading a replica vs the leader. I name the failure mode first, then which letter we optimize."

Common follow-up questions

Is MongoDB CP or AP? Depends on write concern / read concern and replica set election; not one label for all deployments.
Does CAP mean you can't have consistency and availability? Only during a partition in the formal argument; many systems are strongly consistent when the network is healthy.
Where does linearizability fit? It is a consistency model, not CAP's "C" alone—interviewers may bridge to consistency-models.md.

Cross-links (building blocks)

Replication, consensus, and multi-region designs instantiate CAP/PACELC—see System design curriculum overview.

On this page