PACELC Theorem

PACELC — pronounced “pass-elk” — is Daniel Abadi’s 2012 extension of the CAP Theorem that fixes one of CAP’s most operationally annoying gaps: CAP only describes what happens during a network Partition, but partitions are rare; the everyday cost of a distributed system is the latency-vs-consistency trade-off in the normal case, which CAP says nothing about. PACELC restates the trade-off as: “If there is a Partition (P), how does the system trade off Availability (A) and Consistency (C)? Else (E), when the system is running normally in the absence of partitions, how does it trade off Latency (L) and Consistency (C)?” The acronym therefore decomposes into four classes — PA/EL, PA/EC, PC/EL, PC/EC — each giving a richer picture of a system’s actual production behavior than CAP’s PA-vs-PC binary. PACELC was published in IEEE Computer’s February 2012 issue, in the same special section as Brewer’s CAP retrospective (“CAP Twelve Years Later”); it has since become the more practically-cited framework when comparing real distributed databases. Cassandra is PA/EL (Dynamo-style); Spanner is PC/EC (TrueTime + Paxos); MongoDB is PA/EC; PostgreSQL with synchronous replication approximates PC/EC. The “EL” branch is what most production engineers actually grapple with, because partitions are minutes a year while latency-vs-consistency choices fire on every request.

1. Plain-Language Statement

CAP’s framing is “during a network partition, choose C or A.” The natural follow-up question — “okay, but what’s the trade-off when there’s no partition?” — has a non-trivial answer that CAP does not address. In a distributed system without partition, the trade-off is between latency and consistency. Stronger consistency (cross-replica coordination, quorum reads, leader serialization) costs latency. Weaker consistency (read from any local replica, accept stale values) is faster.

PACELC simply names this everyday trade-off and combines it with CAP’s partition-time trade-off into a four-axis classification:

• P (Partition): A or C? — the CAP question, restricted to partition time.
• E (Else): L or C? — the normal-time question, asking how the system trades latency against consistency.

The four resulting classes:

• PA/EL — partition-time: prefers Availability. Normal-time: prefers Latency. Always favors “respond fast and possibly stale” over “wait for consistency.” The Dynamo/Cassandra-style end of the spectrum.
• PA/EC — partition-time: prefers Availability. Normal-time: prefers Consistency. Stays up during partition (accepting stale reads) but pays for consistency in normal operation. MongoDB with majority writes is roughly here.
• PC/EL — partition-time: prefers Consistency. Normal-time: prefers Latency. Refuses writes during partition but reads from local replicas otherwise. Theoretical; rarely seen in practice because the asymmetry is operationally awkward.
• PC/EC — partition-time: prefers Consistency. Normal-time: prefers Consistency. Always pays for consistency, regardless of network state. Spanner, traditional Postgres with sync replication.

The PACELC framing is more useful than CAP for vendor selection. CAP tells you what happens during partitions, which are rare; PACELC tells you the cost the system pays every request, which is what dominates user-perceived latency and operational behavior. A system can be “PA” by CAP but its EL branch is what actually shapes day-to-day performance — and a “PC” system’s EC branch is what makes its writes 50ms slower than its competitors’.

2. Formal Definition

Abadi’s 2012 paper formalizes PACELC as a refinement of CAP:

Definition (PACELC). A distributed data store is classified by two independent properties:

1. Partition behavior: when the network is partitioned (some replicas cannot communicate with others), the system either (a) gives up Availability to preserve Consistency — denoted PC — or (b) gives up Consistency (in the linearizable / strong sense) to preserve Availability — denoted PA.

2. Normal-time behavior: when the network is healthy and all replicas can communicate, the system either (a) gives up Latency (pays the round-trip cost of cross-replica coordination) to preserve Consistency — denoted EC — or (b) gives up Consistency (returns possibly-stale data from a local replica) to preserve Latency — denoted EL.

The four combinations PA/EL, PA/EC, PC/EL, PC/EC are the four PACELC classes. Each is an independent choice, so a system’s PACELC class is more informative than its CAP class.

The “C” in PACELC. Like CAP’s C, PACELC’s C is linearizability — the strong consistency model where every read sees the latest committed write. This is not the same as ACID’s C (application invariants — see ACID Transactions). The same letter, used for three different concepts (CAP-C, ACID-C, PACELC-C); when discussing systems, always disambiguate which “C” you mean.

The “L” in PACELC. Latency in this context specifically means the per-request additional latency from coordination — typically a network round trip for a strongly consistent read or a multi-replica acknowledgment for a write. EL means “skip the coordination, return from a local replica”; EC means “do the coordination, return only consistent results.” For cross-region deployments, EC’s coordination can be 50–200ms; EL is sub-millisecond.

The “Else” in PACELC. “Else” specifically means “the partition is not active.” It’s the everyday operating state. Modern distributed systems spend the overwhelming majority of their time in the E branch — minutes per year are spent in active partitions, but every single request is in the E branch most of the time. This asymmetry is exactly why Abadi argued CAP alone was insufficient.

3. Origins

CAP’s gap

CAP Theorem (Brewer 2000 PODC keynote, Gilbert + Lynch 2002 SIGACT News proof) reframed distributed-systems thinking around the impossibility of simultaneously providing Consistency, Availability, and Partition tolerance. By 2010, CAP was the dominant framework for discussing distributed databases, but it had a frustrating limitation: it described behavior under partition but said nothing about normal operation. Practitioners noticed: Cassandra and DynamoDB were both “AP” systems, but they had quite different normal-time behaviors. Conversely, Spanner and a single-master MySQL were both “CP” in some sense, but their everyday latency stories were dramatically different. The CAP class was failing as a discriminator.

Abadi’s intervention

Daniel Abadi, then a Yale CS professor, started writing about CAP’s shortcomings on his blog “DBMS Musings” in 2010. The relevant post — “Problems with CAP, and Yahoo’s little known NoSQL system” (April 2010) — argued that CAP missed the most-important trade-off in real systems: latency vs consistency in normal operation. He pointed at Yahoo’s PNUTS system as one that explicitly traded latency for consistency, even in the absence of partitions, and argued this trade was at least as important as CAP’s partition-time choice.

Abadi formalized this into PACELC in IEEE Computer, February 2012, in a paper titled “Consistency Tradeoffs in Modern Distributed Database System Design: CAP Is Only Part of the Story” (Abadi 2012). The paper appeared in the same issue as Brewer’s “CAP Twelve Years Later” retrospective — a deliberate juxtaposition by the editors to present both views.

The paper’s argument runs:

1. CAP’s framing focuses on partition time, but partitions are rare in well-engineered networks.
2. The most-relevant consistency trade-off for users and developers is the per-request latency cost of strong consistency.
3. A system’s overall behavior is therefore better characterized by both its partition-time choice (PC vs PA) and its normal-time choice (EC vs EL).
4. The four resulting classes — PA/EL, PA/EC, PC/EL, PC/EC — give a more practical taxonomy of distributed databases.

Reception

PACELC was well-received in academia and gradually adopted in industry. By 2015, most distributed-database technical reviews mentioned PACELC alongside CAP. It is now standard vocabulary for distributed-database design discussions, especially for vendor comparisons and architectural decision documents. The paper itself is short (6 pages) and accessible, and Abadi’s blog has continued to refine the framework.

4. The Four Classes

4.1 PA/EL — Partition: Availability; Else: Latency

The “always favor performance over consistency” class. During a partition, return possibly-stale data rather than refuse service. In normal operation, return from the closest replica without coordinating; consistency is best-effort.

Examples:

• Apache Cassandra at consistency level ONE. Reads return from the nearest replica; writes are acknowledged on a single replica (with async replication to others). During partition: continues serving on each side independently; convergence happens on heal. Normal operation: sub-millisecond reads, no cross-replica coordination.
• Amazon DynamoDB with eventually-consistent reads (the default). Reads from any of the three replica copies; writes acknowledged after one replica. During partition: the side with the partition key’s replicas continues; convergence on heal.
• Riak. Dynamo-style throughout.
• Apache CouchDB with multi-master replication.
• Voldemort (LinkedIn’s Dynamo derivative).

Why PA/EL is popular. Most internet-scale workloads are read-heavy and tolerant of brief staleness — social timelines, product catalogs, recommendation results, like counters. PA/EL minimizes per-request latency, which directly improves user-perceived performance and infrastructure efficiency. The cost is occasional stale reads, which are usually invisible to users.

4.2 PA/EC — Partition: Availability; Else: Consistency

A less-common combination: stay available during partition (accept staleness then), but pay for consistency in normal operation. This works when the application tolerates partition-time inconsistency (or partitions are rare enough not to matter) but wants linearizability when the system is healthy.

Examples:

• MongoDB with writeConcern: majority and reads from primary. Writes wait for majority ack (consistency in normal operation); during partition, the side with majority continues to serve, the minority side may be available for reads but with stale data.
• Yahoo! PNUTS (the system Abadi cited in his original 2010 blog post). Per-record-master replication: the master serves linearizable writes when reachable; during partition, the side without the master can still serve eventually-consistent reads.

Why PA/EC is rarer. It’s an awkward sweet spot — most use cases that need EC also need PC (you don’t typically want to be strongly consistent in healthy operation but accept divergence during partition). The most common deployment is the “I want consistency by default, but don’t want my service to refuse writes during a network blip” stance — operationally, this is a difficult contract to honor cleanly.

4.3 PC/EL — Partition: Consistency; Else: Latency

The mirror image: refuse to serve during partition (consistency stance), but in normal operation, prefer fast local reads over coordinated reads. This combination is rare in practice because the asymmetry — strict consistency under partition, but loose consistency normally — is operationally weird and difficult to provide guarantees for.

Examples: Genuinely few. Some configurations of distributed systems with leader-based writes plus loose follower reads (e.g., MySQL primary with async read replicas, where reads from the replica are stale by default but writes are blocked during partition without the primary). This is less an intentional class and more an artifact of replication topology.

4.4 PC/EC — Partition: Consistency; Else: Consistency

Always-consistent. Refuses to serve when consistency cannot be guaranteed; pays the coordination cost on every request. The “old-fashioned” RDBMS plus modern strongly-consistent distributed databases.

Examples:

• Google Spanner (Corbett et al. OSDI 2012). External consistency (linearizable + real-time-respecting) via TrueTime + Paxos-replicated commit logs. Pays consistency cost on every transaction; refuses writes during quorum-loss partitions.
• CockroachDB. Spanner clone using Hybrid Logical Clocks instead of TrueTime. PC/EC at the transactional level.
• PostgreSQL with synchronous replication. Writes wait for replica ack; reads go to the primary. PC during partition (the primary will block writes if synchronous replicas are unreachable, depending on configuration); EC normally.
• Single-node MySQL/Postgres treated as “the database.” Trivially PC (no partition possible inside a single machine) and EC.
• etcd, ZooKeeper, Consul (the consensus-based key-value stores).

Why PC/EC is the right choice for invariant-bearing data. When correctness depends on linearizability — financial ledgers, inventory, distributed locks, leader election — the latency cost of EC is non-negotiable. PC/EC systems are operationally simple at the application level (the database makes strong promises) but operationally complex at the infrastructure level (TrueTime, atomic clocks, GPS, Paxos quorums).

5. Worked Example — Read-Your-Writes Under PACELC

A common interview question: explain how the same operation (a user reads their own most-recent profile update) behaves differently across PACELC classes.

Setup. A user updates their profile bio at time T0. The system has replicas in us-east-1 (closer to the user) and eu-west-1. Replication lag in healthy operation: ~50ms. The user immediately refreshes the page, hitting their nearest replica.

Case A: Cassandra at CL=ONE (PA/EL)

• Write path. User’s POST hits the coordinator in us-east-1, which forwards to the three replicas (across us-east-1 AZs). At CL=ONE, the coordinator acks the write after one replica’s ack. Total write latency: ~3ms (single-AZ).
• Read path. User’s GET hits the coordinator, which routes to the nearest replica. The replica may not yet have the new write (the write might have been acked by a different replica). Read latency: ~1ms.
• What the user sees. A small probability the read returns stale data — old bio. Refreshing again usually fixes it. Read-your-writes is not guaranteed.
• Why this is PA/EL. The system is willing to serve possibly-stale reads in exchange for the lowest possible latency.

Case B: Cassandra at CL=LOCAL_QUORUM (still PA/EL but tuned toward consistency)

• Write path. Coordinator waits for 2 of 3 (LOCAL_QUORUM) acks before responding. Latency: ~5ms.
• Read path. Coordinator queries 2 of 3 replicas, picks the most-recent. Latency: ~5ms.
• Read-your-writes guarantee? Yes within the local data center, with high probability — because the read quorum (2) and write quorum (2) overlap by at least one replica (R + W > N: 2 + 2 > 3). Any read sees at least one replica that saw the write.
• What the user sees. The new bio reliably. Latency is roughly 2× CL=ONE.
• Note. This is still PA/EL by classification (the design philosophy is fast and locally-quorum-consistent); LOCAL_QUORUM is a per-query consistency knob within the PA/EL framework.

Case C: DynamoDB with strongly-consistent reads (PA but EC for this read)

• Write path. DynamoDB always writes to the partition’s primary (eventually replicates to other AZ replicas).
• Read path. Strongly-consistent reads (opt-in, 2× cost) bypass replicas and go to the primary. Latency: ~5ms (single round trip to primary).
• Read-your-writes guarantee? Yes — the read returns the latest write that committed to the primary.
• What the user sees. The new bio. Latency is single-digit ms.
• Note. DynamoDB’s default eventually-consistent reads are PA/EL; strongly-consistent reads are PA/EC for that operation. DynamoDB Transactions are essentially PC/EC for the transaction.

Case D: Spanner (PC/EC)

• Write path. Coordinator waits for Paxos majority ack across replicas (potentially across regions). Latency: 5–50ms (single region) to 100ms+ (multi-region).
• Read path. Strong reads against current Paxos leader; bounded-staleness reads against a follower (still consistent, just slightly behind). Latency: 1–10ms (in-region) to 100ms+ (cross-region strong reads).
• Read-your-writes guarantee? Yes, always — Spanner’s external consistency means linearizability with real-time order.
• What the user sees. The new bio, reliably. Latency higher than PA/EL but Spanner’s TrueTime makes the cost less than naive Paxos would imply.
• What happens during partition? A Paxos quorum loss makes the affected data ranges unavailable for writes. The user gets an error rather than a stale response.

Comparison

System	Class	Write latency	Read latency	Read-your-writes?	Behavior under partition
Cassandra CL=ONE	PA/EL	~3ms	~1ms	Probabilistic	Continues both sides; convergence on heal
Cassandra LOCAL_QUORUM	PA/EL (tuned)	~5ms	~5ms	Yes (in DC)	Side with majority continues
DynamoDB eventually-consistent	PA/EL	~5ms	~3ms	Probabilistic	Continues both sides
DynamoDB strongly-consistent	PA/EC for op	~5ms	~5ms	Yes	Continues, but reads slow
Spanner	PC/EC	5–50ms	1–10ms	Yes (always)	Refuses writes on quorum loss
Postgres single-master	PC/EC (trivially)	~1ms (no replication)	~1ms	Yes	N/A (single node)

The takeaway: PACELC classification predicts the operational latency story far better than CAP class alone. CAP would have grouped Cassandra and DynamoDB together under “AP” without distinguishing how they behave normally; PACELC adds the EL/EC axis that captures the operational difference.

6. Common Misconceptions

6.1 PACELC is a strict choice

Like CAP, PACELC is a useful taxonomy, not a strict either/or. Most modern systems offer per-operation tunability — the default operation might be PA/EL, but specific queries can request PC/EC behavior. DynamoDB’s strongly-consistent reads, Cassandra’s LOCAL_QUORUM, MongoDB’s read concerns, Cosmos’s five consistency levels — all show that the EL/EC choice is increasingly per-query, not per-database. Treating PACELC as definitive forces awkward classification of systems that actually live in two or three classes simultaneously.

6.2 PACELC supersedes CAP

It doesn’t supersede CAP; it extends it. CAP’s PA/PC half is preserved verbatim (and CAP’s formal proof still applies to that half). PACELC adds the EL/EC axis that CAP omitted. You still need CAP to talk about partition behavior; PACELC just adds the normal-operation half.

6.3 The C in PACELC means the same as the C in ACID

It does not. PACELC’s C = linearizability (cluster-wide single-copy semantics). ACID’s C = application-defined invariants (foreign keys, balance ≥ 0). Different concepts; same letter. PACELC’s C is the same as CAP’s C — but neither is the same as ACID’s C. See §6.5 below for the full disambiguation.

6.4 Latency and consistency are always opposed

In normal operation, yes, but the magnitude of the trade depends on physical layout. Inside a single data center, EC might cost 1–5ms; cross-region, EC might cost 50–200ms. EL within a region might be sub-millisecond. The trade-off is real but the pricing is workload-specific. A system that operates entirely within one DC may find EC essentially free; a globally-distributed system may find EC catastrophic for user latency.

6.5 The Three “C”s — A Painful Disambiguation

Distributed-systems jargon has the bad luck of using “consistency” for three different concepts:

• CAP-C = linearizability — every replica reflects the latest write before any subsequent read sees it. Cluster property.
• PACELC-C = same as CAP-C — linearizability. PACELC reuses CAP’s definition.
• ACID-C = application invariants are preserved by every committed transaction. Per-transaction property.

A system can be ACID-C without being CAP-C/PACELC-C: a single-master Postgres with async replicas locally enforces ACID-C (constraints don’t break), but cluster-wide reads can be stale (no linearizability). A system can be CAP-C/PACELC-C without enforcing ACID-C: an etcd cluster is linearizable but doesn’t enforce application invariants like balance ≥ 0 (it just stores key-value pairs).

The right move when discussing systems: always say “linearizability” or “ACID consistency” or “external consistency” or “session consistency” rather than just “consistency.”

6.6 PC always means high availability is sacrificed

Like CAP, PC means during partition the system favors consistency over availability. In normal operation (the E branch), PC/EC systems can have excellent availability — Spanner targets and achieves five-nines because Google’s network rarely partitions and TrueTime makes the EC coordination fast. PC/EC doesn’t mean “this system has poor uptime”; it means “this system’s failure mode under partition is unavailability rather than staleness.”

7. Real-World Implications

7.1 PACELC class is a vendor-selection tool

When choosing a distributed database, the PACELC class predicts:

• Default per-request latency. EL is fast (sub-ms to single-digit ms); EC is slower (5–200ms).
• Behavior during partition. PA continues serving (with staleness); PC refuses writes.
• Application complexity. PA/EL pushes more complexity to the application (conflict resolution, idempotency, staleness handling); PC/EC pushes complexity into the database infrastructure.

Combined with the workload’s tolerance for staleness vs unavailability, the PACELC class often determines fit immediately. A “I need 99.99% read availability and 50ms p95 cross-region” workload screams PA/EL. A “I need linearizable writes and can pay 100ms” screams PC/EC.

7.2 The EL branch dominates production

The single most operationally-impactful insight of PACELC: partitions are minutes per year; latency-vs-consistency happens on every request. A “PA” system whose EL branch costs 1ms vs a “PA” system whose EL costs 5ms — over a billion daily requests — has an enormous aggregate cost difference. CAP’s PA/PC distinction is what people debate; the EL/EC distinction is where the production cost actually lives.

7.3 Multi-region deployments shift the trade-off

Within a single data center, EC’s cost is small (1–5ms). Across regions, EC requires a cross-region round trip — 50ms US-east to US-west, 100ms+ trans-Atlantic, 200ms+ trans-Pacific. This makes PC/EC systems expensive for global deployments, which is why most globally-distributed systems are PA/EL by default (Cassandra spans regions easily). Spanner’s PC/EC global deployments are a heroic engineering effort precisely because the EC trade-off is so brutal at planetary scale.

7.4 Tunable consistency dilutes the classification

As §6.1 noted, modern systems offer per-query consistency knobs. The result: a single database can serve PA/EL queries by default and PA/EC queries on demand. The PACELC class of a workload depends on query mix, not just on the database product. A team using DynamoDB strongly-consistent reads for everything is operationally PA/EC; a team using DynamoDB eventually-consistent reads is PA/EL. Same database, different observed PACELC class.

7.5 Architectural patterns within each class

PA/EL applications. Design for idempotency, conflict resolution (CRDTs, vector clocks, application-level merges), bounded staleness SLOs, read-your-writes via session affinity. The application has to be aware that staleness leaks out. See BASE Properties.

PC/EC applications. Design for cross-region latency, accept that single-row writes are 10–100ms, partition data so that transactions stay local, use SAGAs for cross-region business processes. See ACID Transactions.

8. Comparison Tables

8.1 PACELC class for major systems (2026)

System	CAP class	PACELC class	Notes
Cassandra (default)	AP	PA/EL	Tunable per-query
DynamoDB (default reads)	AP	PA/EL	Strongly-consistent reads → PA/EC for the op
DynamoDB Transactions	CP for transaction	PC/EC for txn	Per-operation choice
Riak	AP	PA/EL	Vector-clock siblings
MongoDB (writeConcern majority, reads from primary)	CP-leaning	PA/EC	Was PA/EL pre-3.6
MongoDB (writeConcern 1)	AP-leaning	PA/EL
HBase	CP	PC/EC	Region servers serialize
etcd	CP	PC/EC	Raft consensus
ZooKeeper	CP	PC/EC	Zab consensus
Consul	CP	PC/EC	Raft
Spanner	CP	PC/EC	TrueTime + Paxos
CockroachDB	CP	PC/EC	HLC + Raft
TiDB	CP	PC/EC
FaunaDB	CP	PC/EC	Calvin-style
PostgreSQL (sync rep)	CP-leaning	PC/EC
PostgreSQL (async rep)	AP-leaning	PA/EL for replicas
MySQL Group Replication	CP	PC/EC
Couchbase	AP	PA/EL
Redis (cluster, default)	AP-leaning	PA/EL	Async replication
Redis (with WAIT command)	configurable	PA/EC for waited writes
Cosmos DB	tunable across all 4 classes	tunable	Five named consistency levels

Verify before quoting in interview

Some classifications above (especially MongoDB pre-vs-post 3.6, DynamoDB transactional behavior) have evolved across versions. Check the current docs before stating any of these as definitive. A common interview-trap question is “is X system CP or AP?” and the right answer is usually “it depends on the configuration and version — let me ask about the specific knobs.”

8.2 Comparison of CAP-only vs PACELC framing

Question	CAP framing	PACELC framing
What does Cassandra prioritize?	Availability over Consistency	PA/EL — fast and stale by default, configurable
What does Spanner prioritize?	Consistency under partition	PC/EC — pays consistency cost everywhere; partitions cause unavailability
Why is Cassandra faster than Spanner?	(CAP doesn’t say)	EL vs EC — Cassandra skips coordination; Spanner pays for it
What’s the cost of strong-consistency-on-demand?	(CAP doesn’t say)	Switching from EL to EC adds round-trip latency per query

The PACELC framing reveals the operational cost that CAP elides.

9. Variants and Extensions

9.1 The five consistency levels in Cosmos DB

Microsoft’s Cosmos DB exposes a five-point spectrum — Strong, Bounded Staleness, Session, Consistent Prefix, Eventual — implemented as a tunable knob spanning roughly EC (Strong) to EL (Eventual). This is the most-explicit operationalization of PACELC’s E branch in a commercial product.

9.2 Causal+ consistency as a midpoint

Causal consistency (used by COPS, by some configurations of Cosmos’s “Session” level) provides a useful middle ground: weaker than linearizability but stronger than eventual. It can be combined with availability and low latency in ways linearizability cannot, sidestepping some of the harshest PACELC trade-offs. Bailis + Ghodsi’s 2013 ACM Queue article surveys these “highly available transactions” results.

9.3 PBS (Probabilistically Bounded Staleness)

Bailis et al. VLDB 2012: model the staleness distribution analytically. Lets you say “with 99% probability, the EL branch returns data ≤ 50ms stale.” Quantifies what the EL branch actually delivers, rather than just labeling it “loose.”

9.4 The Yield/Harvest model

Brewer + Fox 1999: yield = fraction of requests answered; harvest = fraction of data reflected per answer. A more granular framing that pairs naturally with PACELC. A search engine might offer high yield (always responds) at lower harvest (returns from N–1 of N shards) — operationally, this is a PA/EL stance with explicit harvest degradation.

9.5 Spanner’s claim: PC/EC at PA/EL latency

Spanner’s “trick” is that Google’s private network is engineered to minimize partitions, and TrueTime makes EC’s coordination cheap. The result is a system that is formally PC/EC but operationally feels close to PA/EL — high availability AND high consistency. This is engineering, not theorem-violation: PACELC still says EC costs latency; Spanner just makes EC cheap by buying atomic clocks.

10. Pitfalls in Application

1. Treating PACELC as definitive. Like CAP, PACELC is a useful taxonomy but not a strict classification. Most systems have per-operation tunability that lets them straddle classes. Don’t treat “Cassandra is PA/EL” as the whole story — Cassandra at LOCAL_QUORUM behaves more like PA/EC for that query.

2. Ignoring the EL trade-off when latency is the actual driver. Production teams sometimes pick a database based on CAP class (“we need AP”) without examining the EL branch (“how many ms does a default read cost?”). The result: a notionally-correct PA/EL choice with surprisingly slow normal-operation latency because the team didn’t tune the consistency level. PACELC encourages the latency conversation that CAP alone doesn’t.

3. “We’re PA/EL except when…” complexity. Real systems have many per-operation tunables, and the resulting “we’re PA/EL by default but PA/EC for these 12 endpoints and PC/EC for these 3 operations” classification gets unwieldy. Document the choices per endpoint, not per database. Treat PACELC class as a property of the workload, not the database.

4. Confusing the three Cs. PACELC-C (linearizability) is the same as CAP-C, but neither is ACID-C (application invariants). Mixing these in design discussions or interviews signals confusion. Always disambiguate which “consistency” you mean.

5. Picking PC/EC for everything because consistency feels safer. PC/EC systems are unavailable during quorum-loss partitions and pay coordination latency on every request. For high-volume, low-correctness-cost workloads (social feeds, analytics, recommendations), PC/EC is operationally heavier than necessary — you pay the latency cost and the availability risk for guarantees you don’t actually need. Reserve PC/EC for the small set of operations that truly need linearizability.

6. Picking PA/EL for everything because performance feels obvious. PA/EL systems leak inconsistency to the application. For invariant-bearing workloads (money, inventory, locks), PA/EL applications need to implement application-level coordination (idempotency, CRDTs, periodic reconciliation) that essentially recreates the consistency the database isn’t providing. The total complexity of “PA/EL plus app-level consistency” can exceed “PC/EC and let the database handle it.” Choose by workload, not by default.

7. Forgetting cross-region latency. EC’s cost is 1–5ms within a data center, 50–200ms across regions. A multi-region PC/EC deployment has dramatically different operational characteristics from a single-region one. Always state the deployment topology when discussing PACELC class — “PC/EC single-region” and “PC/EC global” are very different operational beasts.

8. Comparing CAP class without PACELC class. “Cassandra and DynamoDB are both AP” is true but missing critical information. They are both PA/EL by default, with different specific latency profiles and conflict-handling strategies. The CAP-only framing flattens distinctions that the PACELC framing exposes. Always state both classes when comparing systems.

11. Common Interview Discussion Points

• “What is PACELC?” Daniel Abadi’s 2012 extension of CAP that adds the normal-operation trade-off between Latency and Consistency. CAP only describes partition-time behavior; PACELC adds the everyday latency-vs-consistency choice. Cite Abadi 2012 IEEE Computer.

• “Why is PACELC more useful than CAP?” Because partitions are rare and the latency-vs-consistency choice fires on every request. CAP doesn’t help you compare two AP systems’ normal-operation behavior; PACELC’s E branch does.

• “Classify [system] under PACELC.” Cassandra: PA/EL. DynamoDB default: PA/EL. Spanner: PC/EC. MongoDB with majority writes: PA/EC. etcd: PC/EC. Note that per-query tuning means classifications are often per-operation rather than per-database.

• “What does the C in PACELC mean?” Linearizability — the same as CAP’s C. NOT the same as ACID’s C (application invariants). Three different “C”s: CAP-C = PACELC-C = linearizability; ACID-C = application invariants.

• “How does Spanner achieve PC/EC at scale?” TrueTime (atomic clocks + GPS) provides bounded global timestamp uncertainty, letting Spanner serialize transactions across regions without coordination. Paxos-replicated commit logs provide the partition-tolerant strong consistency. The combination makes PC/EC feel almost as fast as PA/EL in healthy operation, though latency is still higher than pure local writes.

• “When would you pick PA/EL over PC/EC?” Read-heavy, latency-sensitive, eventually-consistent-tolerant workloads: social feeds, product catalogs, like counters, telemetry, caching, IoT ingestion. The cost of stale reads is low; the value of low latency and high availability is high.

• “When would you pick PC/EC over PA/EL?” Invariant-bearing workloads: financial ledgers, inventory, account balances, distributed locks, leader election, schema registries, configuration management. The cost of staleness is unacceptable correctness violation; the latency cost is tolerable.

• “What’s the difference between Cassandra LOCAL_QUORUM and DynamoDB strongly-consistent reads under PACELC?” Both are PA/EL systems that allow per-query tightening toward EC. Cassandra LOCAL_QUORUM uses a local-DC quorum (R + W > N) to provide consistent reads within the DC; DynamoDB strongly-consistent reads bypass the cache and read from the partition primary. Both pay extra latency for those reads; both keep the system AP under partition. The mechanisms differ but the PACELC effect is similar.

12. Quick-Reference Cheat Sheet

For interview recall:

• Acronym: Partition: Availability vs Consistency; Else: Latency vs Consistency.
• Origin: Daniel Abadi 2012 IEEE Computer “Consistency Tradeoffs in Modern Distributed Database System Design: CAP Is Only Part of the Story.” Earlier articulated on his “DBMS Musings” blog (April 2010).
• Four classes: PA/EL, PA/EC, PC/EL, PC/EC.
• Canonical PA/EL: Cassandra, DynamoDB default, Riak.
• Canonical PA/EC: MongoDB with majority writes; Yahoo PNUTS.
• Canonical PC/EL: rare; some replication topologies.
• Canonical PC/EC: Spanner, CockroachDB, etcd, ZooKeeper, single-master Postgres.
• The C: linearizability, same as CAP-C, NOT ACID-C.
• Why it matters more than CAP for selection: partitions are minutes/year; latency-vs-consistency happens every request.
• Tunable systems blur the classification: the PACELC class is now per-operation, not per-database, in most modern systems.

13. See Also

• CAP Theorem — the original framework PACELC extends
• ACID Transactions — the local-database property bundle; ACID-C ≠ PACELC-C
• BASE Properties — the AP-side counterpart; PA/EL systems typically embrace BASE
• Consistent Hashing — partitioning primitive used by both PA and PC systems
• Raft — consensus algorithm typical of PC/EC systems
• Paxos High-Level — Spanner’s PC/EC consensus substrate
• Two-Phase Commit — distributed atomic-commit primitive often discussed alongside PACELC
• Distributed Key Value Store System Design — typical PA/EL production architecture
• Distributed SQL Database System Design — typical PC/EC production architecture
• Leaderless Replication Architecture — typical PA/EL topology
• Leader-Follower Replication Architecture — often PC/EC primary + PA/EL replicas
• Multi-Leader Replication Architecture — usually PA/EC or PA/EL
• SWE Interview Preparation MOC
• Major System Designs MOC