PACELC
An extension of CAP (Consistency, Availability, Partition-tolerance): under Partition choose A or C, Else (normal operation) choose Latency or Consistency.
What it is
PACELC, proposed by Daniel Abadi, fixes CAP's biggest blind spot: CAP only describes behavior during a partition, but partitions are rare. The interesting daily tradeoff is between latency and consistency in normal operation. PACELC classifies a system with two letters: PA/EL (Dynamo, Cassandra — available under partition, low latency normally) or PC/EC (Spanner, HBase — consistent under partition, consistent normally) or hybrids like PA/EC.
Why senior interviewers ask
PACELC is the senior-level upgrade to CAP. Quoting PACELC instead of CAP signals you've actually read the distributed systems literature, not just the AWS marketing pages.
Key points
- PA/EL: Cassandra, DynamoDB (default), Riak — favors availability and latency, eventually consistent.
- PC/EC: Spanner, HBase, BigTable — favors consistency always, pays latency cost (multi-region writes).
- PA/EC: MongoDB (default) — available during partition (with stale reads briefly), consistent normally.
- PC/EL: rare and awkward — would mean 'consistent under partition but loose normally'.
- The 'else' branch is where 99% of real traffic lives — design for it.
- Latency cost of consistency: cross-AZ ~1-2ms, cross-region ~50-150ms per round trip.
Real systems
Interview probe
'You said you'd use Cassandra — what does it pick under PACELC, and is that right for this use case?' Answer: PA/EL. Right for high-write IoT/timeseries; wrong for financial ledger where you'd want PC/EC like Spanner.
Dive deeper
PACELC matters because the partition case is rare — maybe a few minutes a year. The latency-vs-consistency tradeoff happens on every single request. A system that's 'CP' under CAP might still expose you to read-your-writes anomalies in normal operation if it allows reads from followers. PACELC forces you to name what the system does in the common case, not just the failure case.