The PACELC Theorem
Extending CAP with Latency Trade-Offs
📅 Last updated: March 10, 2025
Hello! In this post, we will extend the CAP theorem with PACELC, a more complete model for distributed systems. First, we will first recap CAP, then introduce PACELC and explore why it’s needed.
The CAP Theorem
CAP defines three properties:
Consistency (C): Every read request receives either the most recent write or an error. In CAP, consistency refers to a different concept than in ACID; here it means linearizability.
NOTE: Linearizability is the strongest consistency model—it ensures that all users see updates in the same order and changes are immediately visible across, regardless of the number of replicas.
Availability (A): Every request receives a non-error response, even if it may not contain the most up-to-date data.
Partition tolerance (P): The system continues to operate correctly even if communication between some nodes is lost due to network issues (e.g., dropped or delayed messages).
The CAP theorem states that among consistency (C), availability (A), and partition tolerance (P), we can only pick any two.
Since it’s infeasible for a system not to be tolerant of network partitions—network instability is inevitable in distributed systems—the practical choice is between Consistency (C) and Availability (A).
Introducing PACELC
PACELC extends CAP by considering a second trade-off, even where there is no network partition. The theorem states:
If a partition occurs (P), should we favor availability (A) or consistency (C)?
NOTE: This first branch is the same as the CAP theorem.
Else, in the absence of partition (E), should we favor latency (L) or consistency (C)?
Systems can be PA or PC, and they can be EL or EC. Therefore, instead of making a single trade-off as in CAP, PACELC requires us to consider two independent decisions: one for partition scenarios and another for normal conditions.
This results in four possible system designs:
PA/EL (e.g., Amazon DynamoDB): Prioritizes availability during partitions and low latency in normal conditions.
PC/EC (e.g., CockroachDB): Prioritizes consistency over availability during partitions and consistency over latency otherwise.
PA/EC: Available during partitions but ensures strong consistency when there are no network issues.
PC/EL: Consistent during partitions but optimized for low latency in normal conditions.
In practice, PA/EL and PC/EC are the most common trade-offs:
High-availability systems (PA) often favor low latency (EL) to ensure responsiveness. This is generally the case for NoSQL databases such as Cassandra, DynamoDB, and Riak.
Strongly consistent systems (PC) tend to prioritize consistency even in normal conditions (EC). This is generally the case for traditional SQL databases and NewSQL databases such as Google Spanner or CockroachDB.
Why Do We Need PACELC?
While CAP focuses on network partitions, it ignores latency, which is critical in real-world applications.
In the PACELC theorem, latency refers to the upper-bound limit during which a request should receive a non-error response (e.g., 500 ms). One major limitation of the CAP theorem is that it doesn’t explicitly consider latency. Hence, a system could technically be considered available even if it takes an impractically long time to respond, such as 30 minutes.
PACELC fills this gap by explicitly incorporating latency as a key consideration in system design, allowing us to evaluate not only how a system behaves during network partitions but also its real-time performance and responsiveness under normal conditions.
📚 Resources
More From the Distributed Systems Category
Sources
Explore Further
What are your thoughts on the trade-offs introduced by PACELC? Have you already encountered such trade-off decisions?