#18: The PACELC Theorem
Hello! Today, we will extend the CAP theorem introduced yesterday with a new theorem: PACELC.
PACELC is an extension of the CAP theorem, introduced by Daniel Abadi. It’s an acronym that stands for:
P: Partition
A: Availability
C: Consistency
E: Else ← New
L: Latency ← New
C: Consistency
While the core concepts remain similar to those in the CAP theorem, PACELC extends the idea by introducing a second decision point. Let’s explore what the theorem is about and why it matters.
The PACELC theorem expands the CAP theorem with two key questions:
In the case of a network partition (P), should we favor availability (A) or consistency (C)?
But 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. So, instead of making a single trade-off as in the CAP theorem, PACELC requires us to consider two decisions. These decisions impact how a system behaves under partition and normal conditions. For example:
Google Spanner: Prioritizes consistency over availability during partitions (PC) and consistency over latency otherwise (EC). Spanner is known as PC/EC.
Amazon DynamoDB: Prioritizes availability over consistency during partitions (PA) and latency over consistency otherwise (EL). DynamoDB is known as PA/EL.
But wait… we introduced the PACELC theorem, but we haven’t discussed yet why this extension of the CAP theorem was needed in the first place.
Yesterday in #17: The CAP Theorem, we mentioned that, in practice, it was infeasible for a system not to be tolerant of network partitions. Hence, in essence, the CAP theorem was really about choosing either consistency or availability. This is what the first PACELC branch (“If yes”) is about.
Yet, what about normal conditions when there’s no network partition? That’s what the PACELC theorem introduces with the other branch (“else”). It helps us reason about the behavior of a system in the nominal scenario: should we favor latency or consistency?
Latency in the context of the PACELC theorem is an upper-bound limit during which a request should receive a non-error response (e.g., 500 ms). One limitation of the CAP theorem, if not the most important one, is that it doesn’t account for latency, meaning that theoretically, a system could be considered available even if it takes an impractically long time (e.g., 30 minutes) to respond.
This missing dimension—latency—filled by PACELC, provides a more comprehensive framework for reasoning about distributed systems, ensuring we consider not only partition scenarios but also the real-time impact of latency on client experiences.
Tomorrow, we will explore another fundamental concept in databases: the safety and liveness properties.