PACELC Theorem

framework · computer science · formal-scientific

Extension of CAP: even without partitions, systems trade latency against consistency.

The PACELC Theorem, articulated by Daniel Abadi in 2010 ('Problems with CAP, and Yahoo's little known NoSQL system'), extends CAP by capturing a trade-off CAP misses: even when the system is not experiencing a partition, replication-based distributed databases must trade latency against consistency. The acronym reads: if Partition (P), then trade Availability (A) versus Consistency (C); Else (E), trade Latency (L) versus Consistency (C). Different distributed databases make different default PACELC choices: PA/EL (Cassandra, DynamoDB at certain configurations); PC/EC (Spanner, BigTable); PA/EC (MongoDB at certain configurations); PC/EL (less common). The theorem's analytical contribution is making explicit that CAP-style consistency-availability trade-offs apply only during partitions, while a separate consistency-latency trade-off applies the rest of the time — meaning system design choices have effects every day, not just during outages. PACELC has substantially clarified distributed-database design discussions.

Originators

Daniel J. Abadi high

Year / Decade

2010 (Abadi blog post and subsequent paper); 2012 (IEEE Computer formal article) high

Primary sources

Abadi, D.J. (2010). 'Problems with CAP, and Yahoo's little known NoSQL system' (DBMS Musings blog), Abadi, D.J. (2012). 'Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story', IEEE Computer high

Core components

If Partition (P), trade Availability (A) vs Consistency (C)
Else (E), trade Latency (L) vs Consistency (C)
System classification (PA/EL, PC/EC, PA/EC, PC/EL)
Latency-consistency trade-off applies during normal operation, not just partitions
Connection to replication choice and synchronous vs asynchronous replication

Primary use case

Distributed database design and selection; analytical framework for understanding everyday-operation trade-offs in distributed systems beyond partition-only thinking; teaching tool for distributed-systems courses; reference in evaluating database default consistency levels and tunable consistency.

Common criticisms

Less widely-known than CAP and sometimes treated as a footnote rather than substantive extension
binary classifications (PA/EL etc.) oversimplify systems that offer tunable consistency per operation
doesn't address the spectrum of consistency models between strong and eventual (causal, sequential, snapshot, etc.) which contemporary distributed-systems work has elaborated
like CAP, can be invoked to dismiss design space that is actually achievable
the latency-vs-consistency trade-off is real but quantitatively small in some configurations relative to other latency factors.

Lineage

Child of: CAP Theorem
Siblings: CAP Theorem, ACID Properties, BASE Properties
Derived from: CAP Theorem