What does PACELC add to CAP, and how would you classify a few well-known systems with it?
Key points
- If Partitioned, trade Availability vs Consistency, Else trade Latency vs ConsistencyIn plain words: During a network split you choose between staying up and staying in agreement, and the rest of the time between speed and agreement
- Captures that even with a healthy network, synchronous coordination costs latencyIn plain words: Even when nothing is broken, making copies agree before answering takes extra time
- PA/EL systems (Dynamo, Cassandra, DynamoDB default) favour availability and low latency with eventual consistencyIn plain words: Some systems pick staying up and answering fast, and accept that copies agree a little later
- PC/EC systems (Spanner, ZooKeeper, single-leader with sync replication) pay latency for strong consistency alwaysIn plain words: Others always wait for agreement and accept slower answers
- Mixed classes exist, e.g. PA/EC or PC/EL, and the class can vary per operationIn plain words: Mixtures exist too, and one system can choose differently for different requests
Model answer
CAP only speaks about what happens during a partition, which is a small fraction of a system's life. PACELC (Abadi, 2012) fills in the rest:
If there is a Partition, choose between Availability and Consistency; Else, choose between Latency and Consistency.
The second half is the everyday tradeoff. Strong consistency means a write must be coordinated across replicas (a quorum, a leader round trip, a consensus round) before it is acknowledged, and every one of those is a network hop. Giving that up buys latency.
Classifying systems
| System | Partition | Else | Why |
|---|---|---|---|
| Dynamo, Cassandra, Riak | PA | EL | Always writable, tunable but default to fast eventual reads |
| DynamoDB (default reads) | PA | EL | Eventually consistent reads are default and cheaper |
| Spanner, CockroachDB | PC | EC | Consensus on every write, external consistency |
| ZooKeeper, etcd | PC | EC | Linearizable writes, majority quorum |
| MongoDB (majority write concern) | PC | EC | Leader-based, refuses writes without majority |
| PNUTS (Yahoo) | PC | EL | Gives up consistency for latency normally, but not during partitions |
The classes are not fixed per product. Cassandra with QUORUM reads and writes leans toward EC; DynamoDB with strongly consistent reads is EC for those reads. Say "for this operation" when you classify.
Using it in interviews. When you propose cross-region replication, state the PACELC class you are choosing and what the user sees: "writes commit in the home region and replicate asynchronously, so we are PA/EL; a user who changes their profile in Tokyo and immediately reads it from Frankfurt may see the old value for a second. We will route a user's reads to their home region to hide that."
Likely follow-ups
- Why does Spanner accept higher write latency, and how does TrueTime help it?
- Which PACELC class does a read replica with async replication put you in?