CAP & PACELC

CAP in one minute

During a network partition, a replicated system must choose:

• Consistency — all clients see the same data (linearizable reads/writes), or
• Availability — every request gets a response (possibly stale).

Partition tolerance (P) is not optional in real WAN deployments — partitions happen. So the real trade-off is C vs A under partition.

Most production systems choose availability + eventual consistency for some paths, and strong consistency only where the product requires it (often via a smaller coordination layer or single leader).

What CAP does NOT say

• It does not mean "pick two of three" at all times — only during a partition.
• It does not rank systems as "CP" or "AP" forever — same system can offer different guarantees per operation.
• It is not an excuse to skip thinking about consistency — clients still need clear semantics.

PACELC (the follow-up interviewers want)

Daniel Abadi's refinement:

If Partition, choose A or C; Else (normal operation), choose Latency or Consistency.

Examples in conversation:

• Dynamo-style — PA/EL (available under partition, low latency when healthy, eventual consistency)
• Traditional RDBMS primary-replica — PC/EC (consistent, may sacrifice availability under partition on the minority side)

How to answer in an interview

1. State that partitions are inevitable at scale.
2. Explain which operations need strong consistency (money, uniqueness constraints) vs which tolerate staleness (feeds, recommendations).
3. Name the mechanism: leader-based replication, quorums, version vectors — not just "we use Cassandra."

Link forward

Topic 2 names the consistency models; Topic 3 shows how replication and quorums implement these trade-offs in practice.