Stackbook Logo
data-consistencyestablished · low operational burden

PACELC

Also known as: pacelc-theorem

Intent

Extend CAP by also modeling the latency versus consistency tradeoff that exists when there is no partition.

Problem

CAP describes only failure scenarios, yet systems spend almost all of their time healthy. Replication still forces a choice between fast responses and strongly consistent ones.

Forces

  • •Synchronous replication adds round-trip latency
  • •Cross-region distances set a physical latency floor
  • •Users notice latency daily but partitions rarely
  • •Different data has different freshness needs

Solution

Overview

Daniel Abadi proposed PACELC to fix a blind spot in CAP. The acronym reads: if there is a Partition, trade Availability against Consistency; Else, trade Latency against Consistency. The second half matters most day to day, because replicating synchronously across regions costs round trips that no engineering can remove.

How it works

A write must reach replicas before it is acknowledged. The more replicas you wait for, the stronger the guarantee and the slower the response.

Write acknowledged after:
  1 replica (local)     ~2 ms     EL - reads elsewhere may be stale
  majority quorum       ~40 ms    balanced
  all regions           ~150 ms   EC - every read sees the write

Typical classifications: Dynamo-style stores configured for speed are PA/EL; consensus-based stores such as Spanner are PC/EC; some systems are PA/EC or PC/EL depending on configuration. Use the classification to pick defaults, then override per operation, for example strong reads for balances and local reads for catalogs.

Pitfalls

  • Treating the label as fixed. Most modern databases expose consistency per request.
  • Optimizing for the rare partition case while ignoring the constant latency cost.
  • Forgetting physical limits. Cross-continent round trips are tens to hundreds of milliseconds.
  • Not measuring staleness. EL needs an observed bound, not an assumption.
  • Applying one choice to all data instead of by business need.

Key takeaways

  • PACELC adds the normal-operation latency tradeoff to CAP.
  • Strong consistency across distance always costs latency.
  • Choose per workload and override per operation.
  • Measure latency and staleness to validate the choice.

✓ When to Use

  • •Comparing replicated databases for global deployments
  • •Setting read and write consistency levels
  • •Explaining why strong consistency costs latency even when healthy

✗ When Not to Use

  • •Single-region, single-node databases
  • •When consistency needs are uniform and non-negotiable
  • •As a replacement for measuring real latency

Pros

  • +Covers both failure and normal-case tradeoffs
  • +Explains latency costs of consistency
  • +Gives a simple comparison frame for stores

Cons

  • −Coarse; real systems tune per request
  • −Does not quantify latency or staleness
  • −Classification of products can be contested

Cost Profile

Infrastructure

None: conceptual

Operational

Low: configuration and documentation

Cognitive

Low: builds on CAP

Failure Modes

  • Choosing EC globally and discovering cross-region write latency is unacceptable

  • Choosing EL and serving stale data to workflows that require fresh reads

  • Labeling a product once and ignoring its per-request settings

Real-World Examples

Alternatives

  • cap-theorem

Related Patterns

  • cap-theorem
  • consistency-model-selection
  • quorum-reads-writes
  • multi-region-active-active

Competency Domains

data statedistribution communication