1. Introduction

The PACELC Theorem builds upon the CAP Theorem, which states that in a distributed system, you can achieve only two of the following three properties:

  • Consistency (C) – Every read receives the latest write.
  • Availability (A) – Every request receives a response (success/failure).
  • Partition Tolerance (P) – The system continues to function despite network failures.

While CAP focuses only on network partitions, it doesn't address trade-offs in the absence of network failures. This is where PACELC comes in.


2. What is the PACELC Theorem?

The PACELC Theorem, introduced by Daniel J. Abadi, states:

  • If a network partition occurs (P), the system must choose between Availability (A) and Consistency (C) → CAP trade-off.
  • Else (E), even in normal operation, the system must choose between Latency (L) and Consistency (C).

This means that even when there is no failure, distributed systems have to decide whether to:

  • Prioritize consistency (C) at the cost of higher latency (L).
  • Prioritize lower latency (L) at the cost of relaxed consistency (C).

Example:

  • Amazon DynamoDB: PA/EL → Prioritizes Availability over Consistency during partitions, and Low Latency over Strong Consistency in normal operation.
  • Google Spanner: PC/EC → Prioritizes Consistency over Availability during partitions and Consistency over Latency during normal operation.

3. PACELC Trade-offs in Databases

Type When Partition Happens (P) When No Partition (E) Example Databases
PA/EL Prioritizes Availability Prioritizes Low Latency DynamoDB, Cassandra, Riak
PC/EC Prioritizes Consistency Prioritizes Consistency Google Spanner, CockroachDB
PA/EC Prioritizes Availability Prioritizes Consistency Cosmos DB (Strong Consistency Mode)
PC/EL Prioritizes Consistency Prioritizes Low Latency Hybrid cases, rarely used

4. PACELC vs. CAP Theorem

Feature CAP Theorem PACELC Theorem
Focus Only during network partitions Always (with or without partitions)
Trade-offs Consistency vs. Availability (when P occurs) Consistency vs. Availability (P) & Consistency vs. Latency (E)
Consideration Failure scenarios Normal operation and failure

5. When to Choose Which Database?

Use Case Recommended PACELC Type Example
Banking & Financial Systems PC/EC (Consistency over everything) Google Spanner, PostgreSQL
Social Media Feeds PA/EL (Availability & Low Latency) Cassandra, DynamoDB
E-commerce & Shopping Carts PA/EC (Availability first, then Consistency) Cosmos DB (Session Consistency)
Real-time Chat Systems PA/EL (Availability and Latency) DynamoDB, Firebase Firestore

6. Conclusion

The PACELC Theorem enhances our understanding of distributed system trade-offs by considering both failure cases (P) and normal operation (E).

When designing scalable and fault-tolerant systems, it is crucial to:

Choose the right database based on workload needs.

Balance consistency, availability, and latency according to business priorities.

Understand that trade-offs exist even when the system is running normally.

Would you like me to add any code examples or expand on a specific part? 🚀