Consistency & Transactions

PACELC

Also known as: PACELC theorem

Definition

PACELC extends CAP: if there is a Partition, choose Availability or Consistency; Else — when the network is healthy — choose Latency or Consistency. It captures the trade-off that dominates day to day, since partitions are rare but the cost of a consistent read is paid on every request.

Last reviewed · Part of the Architecture Glossary

In practice

PACELC classifies a system with two letters:

SystemClassificationReading
Cassandra (default)PA/ELAvailable under partition, low latency otherwise
DynamoDB (eventual reads)PA/ELSame posture
SpannerPC/ECConsistent always, and you pay TrueTime commit-wait for it
MongoDB (majority writes)PC/ECConsistency first on both paths
PostgreSQL + async replicaPC/ELPrimary is consistent; replica reads trade freshness for speed

The "else" branch is the one that shows up in a latency budget. A quorum read across three availability zones costs an extra 1–2 ms; across three regions, 60–150 ms. That is not a partition scenario — that is Tuesday.

When it matters

Multi-region architecture, choosing read consistency levels per endpoint, and any design review where "just make it strongly consistent" is proposed without anyone pricing the round trip.

Common mistake

Setting one global consistency level. The right answer is usually per-operation: consistent reads on the balance check, eventual reads on the activity feed. PACELC's value is that it makes that a deliberate per-endpoint decision instead of a database-wide default nobody revisits.

See also

Go deeper