PACELC

Your DynamoDB table is healthy. Every replica is online, no partitions, no failures — and yet on every single read you have to choose: do you accept a possibly-stale value from one replica in 0.5ms, or wait for a quorum and pay 2ms plus 2× the read cost for guaranteed freshness? CAP doesn’t help here because there’s no partition. PACELC is the framing that does — it says even in normal operation, every distributed system trades Latency for Consistency on every request, and that tradeoff happens millions of times more often than the rare partition CAP focuses on. Picking the right side of the Else clause, per data type, is the consistency conversation that actually shapes your bill.

PACELC extends CAP by adding the tradeoff that exists in normal operation — when there is no partition. CAP forces a choice between Availability and Consistency only during a fault. PACELC says that even when the system is healthy, you must still choose between Latency and Consistency on every request.

If Partition:    choose A  (availability)  or  C (consistency)
Else:            choose L  (low latency)   or  C (consistency)

The Else clause is why PACELC is more useful than CAP in practice. Partitions are rare — a well-run cluster may experience one per year. But the latency vs. consistency tradeoff happens on every single read and write.

The Framework

flowchart TD
    Q{Network partition\noccurring?}
    Q -->|Yes| PA[PA — prioritize\nAvailability\naccept stale reads,\nkeep accepting writes]
    Q -->|Yes| PC[PC — prioritize\nConsistency\nrefuse requests until\nquorum restored]
    Q -->|No - normal operation| EL[EL — prioritize\nLatency\nread from nearest replica,\nno coordination overhead]
    Q -->|No - normal operation| EC[EC — prioritize\nConsistency\ncoordinate reads/writes,\npay RTT overhead]

A system is classified as PA/EL, PC/EC, PA/EC, or PC/EL based on which side of each tradeoff it takes.

Real-World System Classifications

Why the Else Clause Matters

Consider a 3-node database cluster with replication factor 3. A network partition affecting 1 node happens perhaps once a year. But every read must answer: should I wait for a quorum response, or return immediately from the closest replica?

Scenario: user reads their own profile
  EL choice: read from replica in same AZ → 1ms, may be 50ms behind primary
  EC choice: read from primary or quorum → 3ms, guaranteed fresh

At 100k reads/second, the difference is:
  EL: ~100,000 req/s × 1ms = 100 CPU-seconds of wait
  EC: ~100,000 req/s × 3ms = 300 CPU-seconds of wait
  EC costs 3× more compute for reads

For most reads (social feeds, product catalog, view counts) the stale-ok choice (EL) is correct and much cheaper. For a small subset (account balance, inventory check, idempotency key lookup) the consistent choice (EC) is required regardless of cost.

Tunable Consistency: Cassandra as the Canonical Example

Cassandra exposes the PACELC tradeoff directly through consistency levels, configurable per-operation:

Read/write consistency level → PACELC position:

ONE    → EL: fastest (1 node), stale possible
TWO    → between EL and EC
QUORUM → EC: majority (ceil(RF/2)+1 nodes), consistent
ALL    → EC: all nodes must ACK, highest consistency, lowest availability
LOCAL_QUORUM → EC within one datacenter (cross-DC operations still async)

RF = 3 (3 replicas):

Write at QUORUM:
  Coordinator writes to all 3 replicas
  Waits for 2 ACKs → returns success
  1 replica can lag; still consistent for reads at QUORUM

Read at QUORUM:
  Coordinator asks 2 replicas
  Takes latest value (by timestamp)
  Guaranteed to overlap with the QUORUM write set → always sees latest write

The overlap guarantee: If W (write quorum) + R (read quorum) > N (replication factor), the read set always contains at least one node from the most recent write set. This is the mathematical basis for consistency in quorum systems.

RF=3, QUORUM: W=2, R=2
W + R = 4 > N = 3 ✓ → consistent

RF=3, ONE: W=1, R=1
W + R = 2 ≤ N = 3 ✗ → stale reads possible

PA/EL with an Escape Hatch

A common pattern is a system that is PA/EL by default but lets you opt into EC per request. DynamoDB is the canonical example: reads are eventually consistent by default, but ConsistentRead=true gives a strongly consistent read at higher latency and higher cost.

The default is EL because most workloads — session state, user preferences, product catalog — tolerate brief staleness. Applications opt into EC selectively for the few operations that require it (inventory reservation, balance checks). This is the PACELC tradeoff made adjustable per request rather than fixed system-wide.

Applying PACELC in System Design Interviews

CAP framing asks: “What happens during a failure?” PACELC framing asks: “What is the latency/consistency behavior of every operation?” The second question is almost always more relevant to design decisions.

Decision framework for each data access:

How to use PACELC in an interview:

Instead of saying “I’ll use Cassandra because it’s AP,” say: “For the activity feed I’ll use Cassandra at LOCAL_ONE — users can tolerate a few seconds of staleness and I want low read latency. For the balance ledger I’ll use the primary replica at LOCAL_QUORUM or route to the SQL primary — staleness here has monetary consequences.”

This framing shows you understand that consistency is a per-operation decision, not a system-level binary.

Test Your Understanding