PACELC Theorem: Beyond CAP to Everyday Trade-offs

CAP's Blind Spot

CAP tells you what happens during a partition (choose C or A). But partitions are rare - maybe a few times a year. What about the 99.99% of the time your network is healthy? During normal operation, you still face a trade-off between consistency and latency. PACELC fills this gap.

PACELC Explained

PACELC breaks down as:

  IF there is a Partition (P):
      Choose Availability (A) or Consistency (C)
  ELSE (E) during normal operation:
      Choose Latency (L) or Consistency (C)

  P-A-C-E-L-C
  | | | | | |
  | | | | | +-- Consistency (normal ops)
  | | | | +---- Latency (normal ops)
  | | | +------ Else (no partition)
  | | +-------- Consistency (during partition)
  | +---------- Availability (during partition)
  +------------ Partition

  The key insight: even without partitions, strongly
  consistent reads require coordination (waiting for
  replicas to agree) which adds latency.

System Classifications

System       PACELC    During Partition    Normal Operation
-----------  --------  -----------------  -------------------
DynamoDB     PA/EL     Available (stale)  Low latency (fast)
Cassandra    PA/EL     Available (stale)  Low latency (fast)
MongoDB      PC/EC     Consistent (wait)  Consistent (wait)
PostgreSQL   PC/EC     Consistent (error) Consistent (always)
Cosmos DB    Tunable   Your choice        Your choice
CockroachDB  PC/EC     Consistent (raft)  Consistent (serial)
Riak         PA/EL     Available (merge)  Low latency (local)

  PA/EL systems: 'Fast always, stale sometimes'
  PC/EC systems: 'Correct always, slow sometimes'
  Tunable:       'You decide per collection/query'

The Latency vs Consistency Trade-off

Reading from nearest replica (EL):

  Client --> [Replica NYC]     5ms response
             (might be stale by 10-50ms)

Reading with strong consistency (EC):

  Client --> [Replica NYC] ---sync---> [Leader Oregon]
             waits for confirmation
             80ms response (cross-country round trip)

  Same data. 5ms vs 80ms. 16x slower for consistency.

  For a page load with 20 DB queries:
  EL: 20 * 5ms  = 100ms total (snappy)
  EC: 20 * 80ms = 1600ms total (sluggish)

  This trade-off hits you on EVERY request,
  not just during rare partition events.

Practical Implications

• For user-facing reads like product catalogs, recommendations, and social feeds: use EL (fast, accept staleness of a few seconds)
• For financial operations like checkout, balance checks, and transfers: use EC (correct, accept higher latency)
• For user's own data like profile edits and settings: use read-your-writes with local replica for a middle ground
• Many modern databases let you choose per-query: DynamoDB strongly-consistent reads cost 2x, Cassandra supports consistency levels per query

Interview Tip

When an interviewer asks about consistency trade-offs, go beyond CAP and mention PACELC: 'CAP only applies during partitions, which are rare. The daily trade-off is between latency and consistency during normal operation. For our product catalog, I would use PA/EL - serving from the nearest replica gives 5ms reads, and slightly stale prices are acceptable. For the payment ledger, I would use PC/EC - I need strong consistency even though reads take 80ms from a remote leader. Modern databases like DynamoDB and Cosmos DB let me make this choice per-query.'

<

/blockquote>

Key Takeaway

PACELC extends CAP to normal (non-partitioned) operation: you must still choose between latency and consistency. Most systems are PA/EL (fast and available, possibly stale). Choose EC for data where correctness outweighs speed. This trade-off affects every read and write decision in your architecture.