CAP Theorem vs PACELC: Understanding Distributed System Trade-offs

The misconception about "pick two"

Most explanations of CAP stop at "pick two out of three." This framing is actively misleading, and interviewers know it.

Here's why: partition tolerance is not optional. You can't "choose to not have partitions" any more than you can choose to not have earthquakes. Partitions happen whether you plan for them or not. If you build a distributed system and don't design for partition tolerance, you haven't built a distributed system — you've built a fragile single-node system that happens to be deployed across multiple machines.

So in practice, the real CAP trade-off is much narrower:

When a partition happens, do you choose consistency or availability?

That's the whole theorem, phrased honestly. You're not picking two of three. You're picking one of two, and only in the moment a partition occurs.

Systems that pick consistency under partition are called CP systems. They refuse to serve requests from nodes that can't verify they have up-to-date data. You get correctness, but you might get errors during network issues.

Systems that pick availability under partition are called AP systems. They keep serving requests even when nodes are out of sync, accepting that different clients might see different values temporarily. You get uptime, but you get stale reads.

If an interviewer asks "is your system CP or AP?" and you answer "it depends on the partition, but we chose CP here because we can't afford to show inconsistent account balances" — you've given a better answer than 90% of candidates.

What's missing from CAP

CAP tells you what happens during a partition. That's useful — but partitions are rare events. Most of the time, your distributed system is running in the normal case, with the network working fine.

What trade-offs does a distributed system make in the normal case?

CAP is silent on this. And that silence matters, because the normal-case trade-offs are the ones that affect your users every single day, not just during a once-a-month network blip.

Here's the trade-off CAP ignores: even with no partition, a distributed system that replicates data across multiple nodes has a choice between latency and consistency.

If you want strong consistency — every read sees the latest write — you need to wait for writes to replicate to all relevant nodes before acknowledging them. That's slow. It adds latency to every write.

If you're willing to accept eventual consistency — reads might briefly see stale data — you can acknowledge writes as soon as they hit one node and let replication happen in the background. That's fast. But for a brief window, different clients can see different values.

This trade-off applies 99% of the time. CAP doesn't capture it. That's what PACELC was invented to fix.

The PACELC theorem

PACELC was introduced by Daniel Abadi in 2010 as an extension to CAP. The name itself encodes the full framework:

If there is a Partition (P), the system must trade off between Availability (A) and Consistency (C) — just like CAP says.

Else (E), when the system is running normally, it must trade off between Latency (L) and Consistency (C).

Read it out loud: "P-A-C / E-L-C." Two trade-offs, two situations.

The breakthrough in PACELC is the ELC half. It captures a trade-off senior engineers make constantly but CAP never acknowledges. Every time you configure a database's replication setting — "acknowledge on one replica" vs "acknowledge on majority" vs "acknowledge on all" — you're making an ELC choice.

PACELC gives you a four-letter classification for any distributed database:

• PA/EL — Chooses availability during partitions, and lower latency otherwise. Maximum responsiveness, weakest consistency.
• PA/EC — Chooses availability during partitions, but prioritizes consistency in the normal case. A common "best of both worlds" position.
• PC/EL — Chooses consistency during partitions, but optimizes for latency otherwise. Rare in practice.
• PC/EC — Chooses consistency in both cases. Maximum correctness, but you pay in latency and availability.

Most real databases fall into PA/EL, PA/EC, or PC/EC. PC/EL exists mostly in theory.

Mapping real databases onto PACELC

This is the part that shows up most often in interviews. You should be able to place the major distributed databases on the PACELC spectrum.

PA/EL systems (availability and low latency)

Cassandra, Amazon DynamoDB, and Riak live here. They're the "high availability no matter what" family — originally designed for Amazon's shopping cart and Facebook's inbox, systems where taking a write matters more than being immediately consistent.

During a partition, these systems keep accepting writes on both sides, reconciling conflicts later. In the normal case, they acknowledge writes as soon as one replica has them, giving you single-digit millisecond latency.

These systems are your default choice when: availability is business-critical, writes should never fail, and your application can tolerate eventual consistency (a few hundred milliseconds of "seeing stale data" is fine). Think: social feeds, shopping carts, session storage, IoT telemetry. If you want to go deeper on NoSQL databases in this family, see NoSQL databases for system design.

PC/EC systems (consistency in both cases)

Google Bigtable, HBase, and Apache ZooKeeper live here. They're the "correctness above all" family — designed for use cases where stale or inconsistent data is worse than no data.

During a partition, these systems refuse to serve reads from nodes that can't verify they're up-to-date. In the normal case, they wait for writes to reach a quorum of replicas before acknowledging, which adds latency but guarantees that any read afterward sees the write.

These systems are your default when: correctness is non-negotiable, and your application can tolerate occasional unavailability. Think: distributed locks, service discovery, configuration storage, financial ledgers.

PA/EC systems (availability during partitions, consistency otherwise)

MongoDB (in its default configuration) lives here, as does CockroachDB in many configurations. These are the "have it both ways" systems that optimize for consistency in the normal case but let you keep serving writes when things go wrong.

MongoDB illustrates this nicely. It runs with a primary and secondaries. All writes go to the primary and replicate asynchronously to the secondaries. In the normal case, you get strong consistency if you read from the primary (EC). But during a network partition where the primary is isolated, MongoDB elects a new primary on the majority side and keeps taking writes — accepting that some unreplicated writes on the old primary will be lost (PA).

MongoDB also gives you knobs. You can configure write concern ("acknowledge on majority") and read concern ("read from majority") to move yourself toward PC/EC — at the cost of latency. Most distributed databases give you these knobs now; the default configuration tells you where the designers think most applications should live.

A caveat on these labels

These classifications aren't permanent. Most modern databases let you tune consistency per-query. DynamoDB can do strongly consistent reads (at 2x the cost). Cassandra lets you set consistency level per operation. Even MongoDB's PACELC classification changes based on which replica set config you use.

So when you say "Cassandra is PA/EL" in an interview, a sharp interviewer might follow up with "can I configure it to behave differently?" The correct answer is "yes — you can dial up consistency with tunable consistency levels, but that's a trade-off against latency and throughput." This is the deep version of the senior answer.

Linking CAP and PACELC to real decisions

Here's how this framework shows up in actual system design choices.

"Should I use strong or eventual consistency for my social media news feed?"

This is an ELC question. The data is replicated; there's no partition (usually). Do you want a write (a new post from someone you follow) to immediately appear on every follower's feed (EC — strong, slow), or is it okay if it appears within a few hundred milliseconds (EL — eventual, fast)?

For a social feed, EL is the obvious choice. A 200ms delay between posting and appearance is invisible to users, and the latency improvement is massive. This is why feeds use AP/EL systems like Cassandra.

"What happens if my checkout service can't reach the inventory database?"

This is a PAC question. There's a partition (or at least a failed connection). Do you keep accepting orders optimistically (PA — might oversell) or block checkout until the partition heals (PC — might lose sales)?

For most e-commerce, you want PC here — overselling is worse than losing a sale. But some businesses (like flash sale sites) choose PA and reconcile inventory later, eating the occasional oversell as a cost of doing business.

"Should I use DynamoDB or Spanner for my core transactional data?"

DynamoDB is PA/EL; Spanner is PC/EC (leveraging Google's TrueTime to achieve strong consistency globally). The answer depends on whether your transactions need external consistency across regions (Spanner) or whether eventual consistency with tunable strong-read options is enough (DynamoDB). If you want to deep-dive on picking between databases like these, see PostgreSQL vs MongoDB vs DynamoDB.

Notice that in none of these examples do I start with the letters. I start with the business decision and use the framework to make the trade-off explicit.