Beyond CAP
PACELC extends CAP by addressing what happens when there are NO partitions.
The Problem with CAP
CAP only addresses partitions:
- What happens during a partition?
- Choose: Consistency OR Availability
But what about normal operation?
- When everything is working fine
- Which do you optimize: Latency OR Consistency?
PACELC Definition
PACELC = Partition (choose A or C) + Else (choose L or C)
If Partition:
Choose: Availability (PA) or Consistency (PC)
Else (normal operation):
Choose: Latency (EL) or Consistency (EC)
Full notation:
- PA/EL: Prioritize availability and latency
- PA/EC: Prioritize availability, then consistency
- PC/EL: Prioritize consistency, then latency
- PC/EC: Prioritize consistency always
PACELC vs CAP
| CAP Choice | PACELC Extension | Example |
|---|---|---|
| AP | PA/EL | Cassandra, DynamoDB |
| AP | PA/EC | CouchDB |
| CP | PC/EL | MongoDB |
| CP | PC/EC | HBase, Spanner |
Why PACELC Matters
CAP: "What happens during failure?"
PACELC: "What happens all the time?"
Real systems operate mostly in normal mode,
not in partition mode. PACELC captures the
normal-mode tradeoff that CAP misses.
Latency vs Consistency
PACELC highlights the latency-consistency tradeoff in normal operation.
The Tradeoff
Strong Consistency:
- Write must replicate to all nodes before acknowledgment
- Latency = Network RTT × Number of nodes
- Higher latency, stronger consistency
Eventual Consistency:
- Write acknowledged immediately
- Background replication
- Lower latency, weaker consistency
Real-World Numbers
Example: 3-node cluster, 10ms network RTT
Strong Consistency (PC/EC):
- Write latency: ~30ms (wait for 2 replicas)
- Read latency: ~10ms (from any node)
- Consistency: Strong
Eventual Consistency (PA/EL):
- Write latency: ~1ms (local write)
- Read latency: ~1ms (local read)
- Consistency: Eventual (may be stale)
Difference: 30x latency improvement for eventual!
PACELC Examples
| System | PACELC | Why |
|---|---|---|
| Cassandra | PA/EL | Always available, fast writes |
| DynamoDB | PA/EL | High availability, low latency |
| MongoDB | PC/EL | Strong consistency by default |
| Spanner | PC/EC | Strong consistency always |
| Cosmos DB | Configurable | User chooses tradeoff |
Tuning PACELC
Many systems allow tuning:
Cassandra:
- Consistency Level: ONE → EL
- Consistency Level: QUORUM → more EC
- Consistency Level: ALL → full EC
DynamoDB:
- Eventually Consistent Reads → EL
- Strongly Consistent Reads → EC
MongoDB:
- Read Preference: primary → EC
- Read Preference: secondary → EL
- Write Concern: 1 → EL
- Write Concern: majority → EC
Practical Applications
PACELC helps you make informed database and architecture decisions.
Decision Framework
Step 1: Identify partition behavior (CAP)
- Is availability or consistency more important?
- Choose PA or PC
Step 2: Identify normal behavior (EL/EC)
- Is latency or consistency more important?
- Choose EL or EC
Step 3: Combine
- PA/EL: Cassandra, DynamoDB
- PA/EC: CouchDB, Riak
- PC/EL: MongoDB, CockroachDB
- PC/EC: Spanner, HBase
System Design Application
Design: Social Media Platform
Component: User Posts
- Partition: AP (always accept posts)
- Normal: EL (low latency writes)
- Choice: PA/EL → Cassandra
Component: User Transactions
- Partition: CP (prevent double-spending)
- Normal: EC (strong consistency)
- Choice: PC/EC → Spanner or PostgreSQL
Component: User Feed
- Partition: AP (always show feed)
- Normal: EL (fast reads)
- Choice: PA/EL → Redis Cache + Eventual DB
Common Patterns
| Use Case | PACELC | Technology |
|---|---|---|
| Session Store | PA/EL | Redis, DynamoDB |
| User Profile | PA/EL | Cassandra |
| Order System | PC/EC | PostgreSQL |
| Analytics | PA/EL | ClickHouse |
| Search | PA/EL | Elasticsearch |
| Inventory | PC/EC | MySQL, PostgreSQL |
PACELC in Interviews
When discussing database choices:
1. State the PACELC classification
2. Explain why it fits the use case
3. Discuss the tradeoffs
4. Mention tuning options
Example:
"For the feed service, I'd use Cassandra (PA/EL)
because we prioritize availability and low latency.
Feed reads need to be fast, and showing slightly
stale data is acceptable."
Practice Problems
Design a scalable PACELC Basics system. Cover high-level architecture, data model, and API design.
Solution
// Complete system design:
// - Functional + Non-functional requirements
// - Capacity estimation
// - Data model (SQL/NoSQL choice)
// - API endpoints
// - Component architecture
// - Scaling strategy
// - Monitoring & reliabilityHow would you scale PACELC Basics to handle 10x the current load? Identify bottlenecks and solutions.
Solution
// Scaling approach:
// 1. Load balancing
// 2. Database sharding/replication
// 3. Cache layer (Redis)
// 4. CDN for static assets
// 5. Async processing (queues)
// 6. Microservices decompositionAnalyze potential failure modes for PACELC Basics and design mitigation strategies.
Solution
// Failure mitigation:
// 1. Redundancy (multi-AZ)
// 2. Circuit breakers
// 3. Retry with backoff
// 4. Dead letter queues
// 5. Health checks
// 6. Graceful degradationQuiz
1. What does PACELC stand for?
2. What is the PACELC classification of Cassandra?
3. Why does PACELC extend CAP?
4. Which PACELC classification would you choose for a banking application?
Flashcards
Question
What is PACELC?
Click to reveal answer
Answer
An extension of CAP: If Partition, choose Availability (PA) or Consistency (PC). Else (normal operation), choose Latency (EL) or Consistency (EC).
Question
What is the difference between CAP and PACELC?
Click to reveal answer
Answer
CAP addresses partitions only. PACELC also addresses normal operation - the latency vs consistency tradeoff when everything is working fine.
Question
What is Cassandra's PACELC classification?
Click to reveal answer
Answer
PA/EL - Prioritizes Availability during partitions and Latency during normal operation. Good for high-throughput, low-latency workloads.
Question
How can you tune PACELC in Cassandra?
Click to reveal answer
Answer
By changing consistency levels: ONE = EL, QUORUM = more EC, ALL = full EC. Higher consistency = higher latency.
Question
What is PACELC Basics?
Click to reveal answer
Answer
PACELC Basics is a key concept in system design.
Revision Notes
Key Takeaways
- 1.PACELC extends CAP by addressing normal operation tradeoffs
- 2.Latency and consistency are always in tension
- 3.Most systems allow tuning the consistency-latency tradeoff
- 4.Choose PACELC based on your specific use case requirements
- 5.PACELC helps explain database technology choices
Interview Tips
- •Use PACELC to justify database choices beyond just CAP
- •Explain the latency-consistency tradeoff in normal operation
- •Discuss how you can tune consistency levels
- •Mention specific PACELC classifications for technology choices
Cheat Sheet
PACELC - Cheat Sheet
Definition:
Extension of CAP:
- If Partition: choose A or C (PA or PC)
- Else: choose L or C (EL or EC)
Classifications:
| System | PACELC |
|---|---|
| Cassandra | PA/EL |
| DynamoDB | PA/EL |
| MongoDB | PC/EL |
| Spanner | PC/EC |
| HBase | PC/EC |
Tradeoff:
- Strong Consistency: Higher latency (wait for replicas)
- Eventual Consistency: Lower latency (write immediately)
Tuning:
- Cassandra: Consistency Level (ONE/QUORUM/ALL)
- DynamoDB: Eventually vs Strongly Consistent Reads
- MongoDB: Read Preference and Write Concern