PACELC Theorem Explained: Beyond CAP

PACELC is a framework for reasoning about distributed database tradeoffs that extends CAP theorem to cover the case CAP leaves out: normal operation, when there’s no network partition at all. It states that if a Partition occurs, a system must choose between Availability and Consistency (the CAP part) — else, when running normally, it must choose between Latency and Consistency. The second half is the useful addition, because partitions are rare but the latency/consistency tradeoff is present on every single request.

Why CAP alone isn’t the full picture

CAP theorem says a distributed system can’t simultaneously guarantee consistency, availability, and partition tolerance — and since network partitions are an unavoidable fact of distributed systems, the real choice is between consistency and availability during a partition. That’s a genuinely important result, but it describes an edge case. Partitions in a well-run system might occur for minutes a year. The rest of the time, the system is making a different, more mundane tradeoff on every read and write: how far does a request have to travel, and how many replicas have to agree, before it’s considered “done”?

That’s the gap PACELC — coined by Daniel Abadi — fills in. It reframes distributed system design as two related questions instead of one: what happens under a partition, and what happens the rest of the time.

The “ELSE” half: latency vs consistency

When there’s no partition, a distributed system replicating data across nodes still has to decide how to handle writes. Two broad strategies:

• Favor consistency (PC/EC in PACELC shorthand): a write isn’t acknowledged until it’s confirmed on enough replicas to guarantee any subsequent read sees it. This is strong consistency, but every write pays the latency cost of that coordination — see synchronous vs. asynchronous replication for the mechanics.
• Favor latency (PA/EL): a write is acknowledged as soon as it hits one node (or a local quorum), and replication to other nodes happens in the background. Writes are fast, but a read immediately after, routed to a different replica, might not see the update yet — the system offers eventual consistency instead of strong consistency.

Neither choice is universally correct; it depends on what the workload actually needs. A banking ledger generally can’t tolerate a stale read. A social media like-counter usually can.

Classifying real systems

PACELC is most useful as a four-letter classification tag for a given system’s default configuration:

• PC/EC — DynamoDB in strongly-consistent-read mode, and traditional relational databases run as a single-writer cluster, prioritize consistency both during partitions and in normal operation.
• PA/EL — Cassandra and DynamoDB in eventually-consistent-read mode prioritize availability during partitions and low latency the rest of the time.
• PC/EL — some configurations split the difference: strict about consistency during a partition, but willing to trade a bit of consistency for speed when everything is healthy.

Most systems that describe themselves as “tunable consistency” — Cassandra’s per-query consistency levels are the classic example — are really letting you pick your PACELC point per operation rather than committing to one classification for the whole database.

PACELC and isolation levels

It’s worth distinguishing PACELC’s system-wide replication tradeoff from database isolation levels, which govern how concurrent transactions on the same node see each other’s changes. PACELC is about consistency across replicas in a distributed system; isolation levels are about consistency across concurrent transactions, often on a single node. A system can have strict isolation and still be PA/EL across its replica set, or vice versa. They’re solving related but distinct problems, and conflating them is a common source of confusion when comparing databases.

PACELC vs CAP at a glance

	CAP theorem	PACELC
Scenario covered	Only during a network partition	During a partition, and during normal operation
Tradeoff	Availability vs. consistency	Partition: availability vs. consistency. Normal: latency vs. consistency
How often it applies	Rare (partitions are infrequent)	Constant (every request makes the ELSE choice)
Practical use	Explains worst-case failure behavior	Classifies a system’s everyday behavior

Why this matters when picking a database

When evaluating a database for a distributed workload, the CAP classification tells you what happens in a rare failure mode. The PACELC classification tells you what the system is optimizing for on an ordinary Tuesday — which is far more likely to affect your application’s user-facing latency and correctness guarantees day to day. If you’re choosing between something like OLTP and OLAP systems, or evaluating a database sharding or partitioning strategy, PACELC gives you a vocabulary for asking the right follow-up question: not just “what happens if a node goes down,” but “what am I giving up on every normal request to get this system’s throughput.” Systems built on consensus protocols like Raft tend to sit firmly on the consistency side of both halves, by design — that’s the point of running consensus in the first place.

The takeaway

PACELC completes the picture CAP theorem starts: partitions force a choice between availability and consistency, but the far more common situation — normal operation — forces a separate choice between latency and consistency. Classifying a database by both halves (PA/EL, PC/EC, or a hybrid) tells you more about its everyday behavior than CAP alone ever could, because CAP only describes what happens in the rare case where something has already gone wrong.