PACELC Theorem

Overview

The PACELC theorem is an extension of the CAP theorem that describes trade-offs in distributed systems both during network partitions and under normal operation. Introduced by Daniel Abadi, PACELC stands for:

• P: Partition tolerance – systems must handle network partitions
• A: Availability – choose availability during partitions
• C: Consistency – choose consistency during partitions
• E: Else – when there is no partition
• L: Latency – minimize response time during normal operation
• C: Consistency – maintain consistency during normal operation

Simply put: "During a partition, choose between availability and consistency; else, choose between latency and consistency."

PACELC provides a more complete model than CAP for reasoning about distributed database trade-offs in real-world systems.

Core Principles

Partition (P) Phase

Definition: When a network partition occurs, the system must choose between:

• Consistency (C): Ensure all nodes have the same view of data, potentially sacrificing availability.
• Availability (A): Serve requests even if nodes may have inconsistent data.

Real-World Examples:

• CP systems during partitions: MongoDB (majority reads), HBase, banking systems
• AP systems during partitions: DynamoDB, Cassandra, DNS systems

Else (E) Phase

Definition: When there is no network partition, PACELC considers trade-offs between latency and consistency:

• Latency (L): Optimize for low response times, potentially sacrificing strict consistency.
• Consistency (C): Maintain strong consistency even if it increases latency.

Real-World Examples:

• Latency-focused: Amazon DynamoDB prioritizes low-latency eventual consistency for high throughput reads.
• Consistency-focused: Google Spanner enforces strong consistency using global clocks, even at the cost of higher latency.

Technical Implementation

During Partitions

• Quorum-based systems: Majority voting to maintain consistency (CP)
• Eventual consistency mechanisms: Asynchronous replication and conflict resolution (AP)

During Normal Operation (Else Phase)

• Synchronous replication: Ensures immediate consistency across nodes (higher latency)
• Asynchronous replication / caching: Reduces latency at the cost of temporary inconsistency

PACELC Trade-off Diagram

System Classification Examples

Practical Implications

For System Design

• Decide which operations require strong consistency vs high availability.
• Optimize latency for read-heavy workloads where eventual consistency is acceptable.
• Prepare for network partitions and plan graceful degradation.

For Database Selection

• CP systems: Google Spanner, HBase → prioritize consistency under partitions.
• AP systems: Cassandra, DynamoDB → prioritize availability under partitions.
• Consider Else trade-offs: low latency vs strong consistency for normal operation.

Practical Implications

For System Design

• Decide which operations require strong consistency vs high availability.
• Optimize latency for read-heavy workloads where eventual consistency is acceptable.
• Prepare for network partitions and plan graceful degradation.

For Database Selection

• CP systems: Google Spanner, HBase → prioritize consistency under partitions.
• AP systems: Cassandra, DynamoDB → prioritize availability under partitions.
• Consider Else trade-offs: low latency vs strong consistency for normal operation.

Interview-Focused Content

Junior Level (2–4 YOE)

Q: What does PACELC stand for?
A: Partition, Availability, Consistency, Else, Latency, Consistency. It extends CAP by considering trade-offs even when there is no network partition.

Q: Why is PACELC more practical than CAP?
A: CAP only considers trade-offs during partitions. PACELC models real-world systems where latency vs consistency matters under normal operation.

Senior Level (5–8 YOE)

Q: How would you choose a PACELC strategy for a social media platform?

• Partition phase: Favor availability to keep feeds live.
• Else phase: Favor low latency for fast content delivery.
• Use eventual consistency with background reconciliation.

Q: How can PACELC inform database selection?

• High-value transactions → choose CP, tolerate higher latency.
• User-generated content → choose AP, optimize for latency.

Staff+ Level (8+ YOE)

Q: How would PACELC guide a globally distributed e-commerce system?
A:

• Payments: CP during partitions, consistency during normal operation.
• Product catalog: AP during partitions, low latency during normal operation.
• Recommendations: AP + low latency, eventual consistency acceptable.

Q: Can PACELC help balance performance and correctness?
A: Yes, by explicitly modeling trade-offs during partitions and normal operation, engineers can tune replication, quorum sizes, and caching per workload.

Further Reading

• CAP Theorem
• PACELC: An Extension of CAP
• Daniel Abadi’s PACELC Paper
• Comparison: CAP vs PACELC