Concept · Consistency & coordination
PACELC
CAP covers partitions; PACELC adds the latency-versus-consistency trade-off the rest of the time.
PACELC extends the CAP theorem to cover the normal case:
If there's a Partition, choose Availability or Consistency; Else (no partition), choose Latency or Consistency.
Why the "else" matters
Partitions are rare. The trade-off you make on every request is latency: to be strongly consistent, a write must reach a quorum or a leader and a read must confirm it sees the latest value, which costs round trips — and across regions, tens to hundreds of milliseconds each.
Classifying systems
| System | During a partition | Otherwise |
|---|---|---|
| Spanner, CockroachDB, etcd | Consistency (PC) | Consistency (EC) — pay the latency |
| Cassandra, DynamoDB (defaults) | Availability (PA) | Latency (EL) — reads may be stale |
| PostgreSQL primary + async replicas | Consistency on the primary | Latency when reading replicas |
| MongoDB (majority read/write concerns) | Consistency (PC) | Consistency (EC) |
Many systems are tunable per request, so the classification describes defaults rather than fixed properties.
Using it in design
Ask two questions for each operation:
- If the network splits, should this keep working with possibly stale data, or refuse?
- Is the latency of a consistent read or write acceptable on the normal path?
A shopping cart might answer "keep working" and "favour latency"; a funds transfer "refuse" and "pay the latency". See consistency models.