17 PACELC Theorem
The CAP theorem tells you what happens during a network partition: choose consistency or availability. But partitions are rare. Most of the time, your system is running normally. During those normal times, what's the trade-off?
CAP says nothing about this. PACELC fills the gap.
Background
CAP tells you: during a partition (P), choose availability (A) or consistency (C). But real systems spend most of their time not partitioned. And even without partitions, there's a fundamental tension: replicating data takes time. If you wait for all replicas to confirm before responding, you get consistency but higher latency. If you respond after writing to one replica, you get low latency but risk stale reads.
This latency-consistency trade-off exists all the time, not just during partitions. CAP doesn't capture it.
Definition
The PACELC theorem (pronounced "pass-elk") extends CAP:
If there is a Partition, trade off Availability and Consistency;
Else (normal operation), trade off Latency and Consistency.
Every replicated distributed system falls into one of four categories:
| Category | During partition | During normal operation | Example systems |
|---|---|---|---|
| PA/EL | Choose availability | Choose low latency | Dynamo, Cassandra |
| PA/EC | Choose availability | Choose consistency | MongoDB (default config) |
| PC/EL | Choose consistency | Choose low latency | (rare -- most CP systems also choose consistency normally) |
| PC/EC | Choose consistency | Choose consistency | BigTable, HBase, Chubby |
Why PACELC matters more than CAP
CAP describes an extreme scenario (partitions). PACELC describes everyday behavior. The "ELC" half is actually more useful for system design because it captures the trade-off you face on every single request:
- Low latency: Respond after writing to one or few replicas. The client is happy (fast response), but some replicas may be stale.
- Strong consistency: Wait for a quorum or all replicas to confirm. The client always sees the latest data, but at higher latency.
When you choose a database, you're mostly choosing the ELC behavior, not the PAC behavior. Partitions are rare; latency vs. consistency affects every request. Dynamo and Cassandra (PA/EL) are fast but eventually consistent. BigTable and HBase (PC/EC) are consistent but slower (replication must complete before responding).
Examples from this course
Dynamo and Cassandra (PA/EL)
During a partition, they keep serving requests (availability over consistency). During normal operation, they respond quickly without waiting for all replicas (latency over consistency). This is the "fast and eventually consistent" profile -- ideal for use cases where stale reads are acceptable.
BigTable and HBase (PC/EC)
During a partition, they refuse requests that can't be served consistently. During normal operation, they wait for replication to complete before confirming writes (consistency over latency). This is the "always correct, sometimes slow" profile -- ideal for use cases where data correctness is non-negotiable.
MongoDB (PA/EC -- default)
An interesting hybrid. During a partition, MongoDB's asynchronous replication means writes acknowledged to the client might be lost if the primary fails, so it effectively chooses availability. But during normal operation, reads from the primary are consistent. This makes MongoDB PA/EC in its default configuration. However, when configured with majority read/write concerns, it behaves more like PC/EC.
PACELC is the answer when an interviewer asks "What about when there's no partition?" or "CAP only covers failure scenarios -- what about normal operation?" The key phrase: "CAP only describes partition behavior. PACELC extends it to cover the latency-consistency trade-off during normal operation, which affects every request, not just failures."