System Design

Beyond CAP: The PACELC Theorem for Distributed Databases

Why the CAP theorem isn't enough. Learn how the PACELC theorem explains the trade-offs between consistency and latency even when there is no network partition.

Sachin Sarawgi·April 20, 2026·2 min read
#distributed-systems#pacelc#cap-theorem#databases#consistency

Beyond CAP: Understanding the PACELC Theorem

Most engineers know the CAP Theorem: in the presence of a network partition (P), you must choose between Consistency (C) and Availability (A). However, CAP only tells us what happens when things go wrong. It says nothing about how a system behaves during normal operations.

This is where PACELC comes in.

1. What is PACELC?

PACELC is an extension of CAP. It is read as:

  • If there is a Partition (P), choose between Availability (A) and Consistency (C).
  • Else (E), choose between Latency (L) and Consistency (C).

2. The Missing Piece: Normal Operations

In a healthy system (no partition), data is replicated across nodes. To ensure Consistency, the system must wait for all replicas to acknowledge a write before replying to the user. This increases Latency.

If you want low Latency, you reply to the user immediately after one node writes, and replicate to others in the background. This results in Eventual Consistency.

3. Categorizing Popular Databases

PC/EC (Consistency Priority)

These systems prioritize consistency at all costs.

  • Example: BigTable, HBase.
  • Behavior: They are consistent during partitions and choose consistency over latency during normal operations.

PA/EL (Availability & Latency Priority)

These systems prioritize speed and uptime.

  • Example: DynamoDB, Cassandra, Riak.
  • Behavior: During a partition, they remain available (PA). During normal operation, they prioritize low latency (EL) via asynchronous replication.

PA/EC (The Hybrid)

  • Example: MongoDB.
  • Behavior: MongoDB is PA because it can lose data during a partition if the primary fails before replication. However, it is EC because, by default, it waits for primary acknowledgment, prioritizing consistency over the lowest possible latency.

4. Why PACELC Matters for Architects

When choosing a database, you need to ask two questions:

  1. "What happens when the network breaks?" (CAP)
  2. "How fast do I need my reads and writes to be when the network is fine?" (PACELC)

If you are building a high-frequency trading system, you likely need PC/EC. If you are building a social media feed where a few seconds of stale data is fine but speed is paramount, you want PA/EL.

Summary

The PACELC theorem provides a more realistic framework for evaluating distributed databases. By acknowledging that latency is a trade-off for consistency even in a healthy network, you can make more informed decisions about your system's performance and data integrity.

📚

Recommended Resources

Designing Data-Intensive ApplicationsBest Seller

The definitive guide to building scalable, reliable distributed systems by Martin Kleppmann.

View on Amazon
Kafka: The Definitive GuideEditor's Pick

Real-time data and stream processing by Confluent engineers.

View on Amazon
Apache Kafka Series on Udemy

Hands-on Kafka course covering producers, consumers, Kafka Streams, and Connect.

View Course

Practical engineering notes

Get the next backend guide in your inbox

One useful note when a new deep dive is published: system design tradeoffs, Java production lessons, Kafka debugging, database patterns, and AI infrastructure.

No spam. Just practical notes you can use at work.

Sachin Sarawgi

Written by

Sachin Sarawgi

Engineering Manager and backend engineer with 10+ years building distributed systems across fintech, enterprise SaaS, and startups. CodeSprintPro is where I write practical guides on system design, Java, Kafka, databases, AI infrastructure, and production reliability.

Found this useful? Share it: