CAP and PACELC — the trade-off you can't avoid
You cannot have consistency, availability, and partition-tolerance all at once. PACELC extends the picture with a latency vs. consistency trade-off when there's no partition.
In a distributed system with a network that can partition, you can have at most two of: Consistency, Availability, and Partition-tolerance. Partitions happen; you don't get to opt out. So the real choice is: when the network splits, do I stay consistent (CP) or stay available (AP)?
PACELC — the fuller picture
CAP only tells you what happens during a partition. PACELC adds the case without a partition: Even in the absence of partitions, Latency and Consistency trade off. A globally strongly-consistent write needs to coordinate; coordination costs time.
Real systems make different choices at different layers. Spanner is CP+C (strong everywhere, latency cost). Cassandra defaults to AP+L (fast, eventual). DynamoDB is AP+L by default, CP+C with strong reads. The decision is per-request, not per-system.
In the interview
Say the letters. Nothing signals system-design fluency faster than stating "this write path is CP because the ledger requires strong consistency; the read path is AP because we can tolerate a 100ms window of staleness." That one sentence covers three decisions.
Practice what you just read
Every foundation concept has a companion quiz to close the loop.