Skip to content

PACELC

1. What is it? (2-3 lines)

PACELC is an extension of the CAP Theorem formulated by Daniel Abadi. It states that If there is a Partition (P), a system must trade off Availability (A) vs Consistency (C); Else (E), even when operating normally without partitions, the system must trade off Latency (L) vs Consistency (C).

2. Why does it exist?

The CAP theorem only describes system behavior during network partitions, which occur rarely (<0.1% of operational time). It fails to explain architectural trade-offs during 99.9% of normal operations. PACELC unifies partition behavior and normal-state latency trade-offs into a complete taxonomy.

3. Where is it used?

  • PC/EC (e.g. Spanner, CockroachDB): Chooses Consistency during partitions AND Consistency (higher latency due to multi-node consensus) during normal execution.
  • PA/EL (e.g. Cassandra, DynamoDB default): Chooses Availability during partitions AND Low Latency (asynchronous replication) during normal execution.
  • PC/EL (e.g. MongoDB primary reads): Chooses Consistency during partitions, but Low Latency for normal reads from secondary nodes.

4. How does it work? (simple flow)

  1. Check System State: Is there an active Network Partition?
  2. If Partition Exists (P):
  3. Option 1 (A): Serve stale local data \(\implies\) PA (High Availability).
  4. Option 2 (C): Reject requests or wait \(\implies\) PC (Strong Consistency).
  5. Else Normal Operation (E):
  6. Option 1 (L): Replicate asynchronously to secondary nodes; return response immediately \(\implies\) EL (Low Latency).
  7. Option 2 (C): Synchronously wait for all replica confirmations before returning success \(\implies\) EC (Strong Consistency).

5. Advantages

  • Provides a comprehensive classification covering both failure states and normal steady-state operations.
  • Explains why synchronous strongly-consistent databases (e.g. Spanner) exhibit higher read/write latency even when healthy.

6. Limitations

  • Does not account for dynamic multi-datacenter network topologies or variable quorum configurations per query (R+W > N).
  • Harder to explain to non-distributed systems stakeholders compared to the simple CAP Theorem.

7. Common interview questions (10)

  1. How does PACELC extend the traditional CAP Theorem?
  2. What does the Else (E) clause in PACELC represent?
  3. How is Apache Cassandra classified under the PACELC theorem (PA/EL)?
  4. How is Google Spanner classified under the PACELC theorem (PC/EC)?
  5. Why does choosing Consistency during normal operations (EC) inherently increase write latency?
  6. How does MongoDB's WriteConcern (w:1 vs w:majority) shift its PACELC classification?
  7. What is the PACELC trade-off of Amazon DynamoDB when configured for Strong Consistent Reads?
  8. How does asynchronous cross-region replication map to PACELC?
  9. Why can a system never achieve both Zero Latency and Strong Consistency during normal operations?
  10. How does PACELC guide the selection of storage engines for financial ledgers vs social media feeds?

8. Common misconceptions

  • Misconception: PACELC replaces the CAP Theorem. Fact: PACELC subsumes and extends CAP by adding normal-state latency vs consistency analysis.
  • Misconception: High latency in normal operations implies bad code. Fact: High latency in EC systems is the mathematical cost of synchronous multi-node consensus.

10. 30-second cheat sheet

  • Formula: If P \(\to\) choose A or C; Else (E) \(\to\) choose L or C.
  • PA/EL: Availability + Low Latency \(\implies\) Cassandra, DynamoDB (Eventual Consistency).
  • PC/EC: Consistency + Consistency \(\implies\) Spanner, CockroachDB (High Latency Consensus).
  • PC/EL: Partition Consistent + Normal Low Latency \(\implies\) MongoDB.