PACELC extends CAP by adding a dimension for trade-offs during normal operation: if there is a network partition (P), choose between Availability and Consistency (A/C), else (E) in the absence of a partition, choose between Latency and Consistency (L/C).
PACELC is an extension of the CAP theorem that addresses a fundamental limitation of the original theorem. While CAP focuses solely on trade-offs during a network partition, it ignores the equally important trade-offs that systems make in normal operation when no partition exists. PACELC captures both scenarios: during a Partition (P), the system must choose between Availability (A) and Consistency (C); Else (E) when there is no partition, the system must choose between Latency (L) and Consistency (C). This extension better reflects the reality of distributed systems, where even in normal operation, engineers make explicit trade-offs between performance and consistency.
P (Partition): When a network partition occurs, the system follows CAP's original constraint: choose between Availability and Consistency.
A/C (Availability or Consistency): During a partition, the system either remains available (accepting potentially stale data) or prioritizes consistency (blocking operations until the partition resolves).
E (Else): When no partition exists—the typical operating state—different trade-offs apply.
L/C (Latency or Consistency): In normal operation, systems choose between faster responses (lower latency) and stronger consistency guarantees.
AP/LC (Availability during partition, Low latency normally): Cassandra, Riak, CouchDB, DynamoDB (eventual consistency). These systems prioritize availability and fast responses, accepting eventual consistency.
AP/PC (Availability during partition, Strong consistency normally): Some configurations allow strong consistency in normal operation but fall back to availability during partitions. Example: MongoDB with write concern majority (PC normally) but may accept writes during partition (AP).
CP/LC (Consistency during partition, Low latency normally): Many distributed SQL databases (CockroachDB, Yugabyte) fall into this category. They provide strong consistency and low latency during normal operation but may sacrifice availability during partitions.
CP/PC (Consistency during partition, Strong consistency normally): Spanner, some PostgreSQL synchronous replication configurations. These systems maintain strong consistency at all times, with higher latency even in normal operation, and may become unavailable during partitions.
PACELC provides a more complete framework for evaluating distributed systems. Engineers using only CAP might incorrectly assume that a system like MongoDB or Cassandra only makes trade-offs during failures. In reality, these systems also make critical latency-consistency trade-offs in normal operation. Understanding PACELC helps designers answer practical questions: "Is the system's normal latency acceptable?" and "What consistency do I get when everything is healthy?"—questions CAP alone cannot answer. The PACELC model has become the standard mental framework for architects selecting databases for real-world applications.
0-2 years experience
2-5 years experience
5-8 years experience
8+ years experience
