CAP, PACELC, and Saying It Out Loud
CAP is two-sentence short, and that's why everyone misuses it. Add PACELC and you get a sentence you can actually defend in an interview.
CAP as usually quoted — 'you can have two of Consistency, Availability, Partition tolerance' — is only true during a partition. The useful version has two halves:
The two sentences
- —CAP: When the network partitions (nodes can't talk), you choose between Consistency (every node answers the same) and Availability (every node answers at all).
- —PACELC: And even WITHOUT a partition, you choose between Latency and Consistency — that's the 'ELC': Else Latency vs Consistency.
The second sentence is the one that changes your interview answers. Without a partition, you're still choosing: do I wait for the replica to catch up (consistency, slower) or answer from what I have (latency, staler)?
Putting products on the map
- —PostgreSQL (single primary, sync replica): CP during partition, consistency-leaning in the ELC.
- —Cassandra: AP during partition — any replica answers; eventual convergence via quorum writes.
- —RDBMS async replica: 'read replicas are fine because I accept bounded staleness' — that's you choosing latency in the ELC not-really-questioningly enough.
The interview sentence
The graded answer sounds like: 'For the payments write path I choose consistency over latency — so the primary does the write and I read my own writes from the primary. For the news feed read path, I accept eventual consistency and bounded staleness in exchange for serving from replicas.' You've now used CAP (partition), PACELC (no partition), and normalized the decision to a per-path choice instead of a religion.