CAP's Blind Spot
CAP tells you what happens during a partition (choose C or A). But partitions are rare, maybe a few times a year. What about the 99.99% of the time your network is healthy? The PACELC Theorem addresses this everyday scenario by highlighting the trade-off between consistency and latency during normal operation. During normal operation, you still face a trade-off between consistency and latency. PACELC fills this gap.
PACELC Explained
PACELC breaks down as:
IF there is a Partition (P):
Choose Availability (A) or Consistency (C)
ELSE (E) during normal operation:
Choose Latency (L) or Consistency (C)
P-A-C-E-L-C
| | | | | |
| | | | | +-- Consistency (normal ops)
| | | | +---- Latency (normal ops)
| | | +------ Else (no partition)
| | +-------- Consistency (during partition)
| +---------- Availability (during partition)
+------------ Partition
The key insight: even without partitions, strongly
consistent reads require coordination (waiting for
replicas to agree) which adds latency.System Classifications
System PACELC During Partition Normal Operation
----------- -------- ----------------- -------------------
DynamoDB PA/EL Available (stale) Low latency (fast)
Cassandra PA/EL Available (stale) Low latency (fast)
MongoDB PC/EC Consistent (wait) Consistent (wait)
PostgreSQL PC/EC Consistent (error) Consistent (always)
Cosmos DB Tunable Your choice Your choice
CockroachDB PC/EC Consistent (raft) Consistent (serial)
Riak PA/EL Available (merge) Low latency (local)
PA/EL systems: 'Fast always, stale sometimes'
PC/EC systems: 'Correct always, slow sometimes'
Tunable: 'You decide per collection/query'The Latency vs Consistency Trade-off
Reading from nearest replica (EL):
Client --> [Replica NYC] 5ms response
(might be stale by 10-50ms)
Reading with strong consistency (EC):
Client --> [Replica NYC] ---sync---> [Leader Oregon]
waits for confirmation
80ms response (cross-country round trip)
Same data. 5ms vs 80ms. 16x slower for consistency.
For a page load with 20 DB queries:
EL: 20 * 5ms = 100ms total (snappy)
EC: 20 * 80ms = 1600ms total (sluggish)
This trade-off hits you on EVERY request,
not just during rare partition events.Practical Implications
For user-facing reads like product catalogs, recommendations, and social feeds: use EL (fast, accept staleness of a few seconds)
For financial operations like checkout, balance checks, and transfers: use EC (correct, accept higher latency)
For user's own data like profile edits and settings: use read-your-writes with local replica for a middle ground
Many modern databases let you choose per-query: DynamoDB strongly-consistent reads cost 2x, Cassandra supports consistency levels per query
Interview Tip
When an interviewer asks about consistency trade-offs, go beyond CAP and mention PACELC: 'CAP only applies during partitions, which are rare. The daily trade-off is between latency and consistency during normal operation. For our product catalog, I would use PA/EL - serving from the nearest replica gives 5ms reads, and slightly stale prices are acceptable. For the payment ledger, I would use PC/EC - I need strong consistency even though reads take 80ms from a remote leader. Modern databases like DynamoDB and Cosmos DB let me make this choice per-query.'
Key Takeaway
PACELC extends CAP to normal (non-partitioned) operation: you must still choose between latency and consistency. Most systems are PA/EL (fast and available, possibly stale). Choose EC for data where correctness outweighs speed. This trade-off affects every read and write decision in your architecture.