Skip to content

Mental Model: PACELC

Category: System Behavior Origin: Daniel Abadi, 2012 ("Consistency Tradeoffs in Modern Distributed Database System Design") One-liner: During a partition, choose between Availability and Consistency; otherwise (the common case), choose between Latency and Consistency — PACELC makes the latency tradeoff explicit where CAP ignores it.

The Model

PACELC extends CAP Theorem by recognizing that CAP only describes system behavior during network partitions. Partitions are rare in well-operated infrastructure; most of the time, the system is healthy. Yet distributed systems still face fundamental tradeoffs even in normal operation: to achieve strong consistency, nodes must coordinate — and coordination takes time. PACELC forces you to state your tradeoff in both regimes.

The model breaks down as: Partition → Availability or Consistency; Else (no partition) → Latency or Consistency. A system's full PACELC classification is expressed as two pairs. For example, Cassandra is PA/EL: during partitions it chooses availability; in normal operation it chooses low latency (by not requiring all replicas to acknowledge before responding). DynamoDB with strong consistency enabled is PC/EC: it sacrifices availability during partitions and accepts higher latency in normal operation to guarantee consistency.

The "Else" clause is the key addition. Consider a system requiring that a write be acknowledged by all three replicas before returning success. In a healthy cluster, this is slow — you pay the latency of the slowest replica. In a partitioned cluster, it is unavailable — one replica is unreachable and you cannot complete the write. The tradeoff between latency and consistency is present at all times, not just during failures. PACELC surfaces this constant tradeoff so engineers can make an explicit choice rather than discovering it under load.

Common PACELC classifications of widely-used systems: - Cassandra: PA/EL — tunable per-operation; default is available and low-latency - DynamoDB: PA/EL (default reads) or PC/EC (strong consistency reads) - etcd / ZooKeeper: PC/EC — consistency always, even at the cost of latency and availability - MySQL async replication: PA/EL — replica lag is a latency-vs-consistency tradeoff - MySQL synchronous replication (Group Replication): PC/EC — writes acknowledged by majority before committing

The PACELC framing is most useful for teams tuning an existing system (e.g., choosing DynamoDB consistency mode per API call) or arguing for one system over another when both are available and partition-tolerant. It reframes the question from "what fails during a partition?" (CAP) to "what do we pay in normal operations?"

Boundary conditions: PACELC, like CAP, assumes a fixed system configuration. Many modern systems are tunable at the request level — DynamoDB, Cassandra, and Riak all allow per-request consistency levels. This means the PACELC classification is not a single point but a line across the L↔C spectrum, and the engineer chooses where on that line each request lands.

Visual

PACELC Decision Framework:

                    Is there a network Partition?
                             │
               ┌─────────────┴─────────────┐
              YES                          NO (Else)
               │                            │
       Choose between:              Choose between:
       ┌───────┴──────┐            ┌────────┴────────┐
       A              C            L                 C
  Availability  Consistency    Latency          Consistency
  (keep serving) (refuse/error) (respond fast)  (coordinate first)

System Classification Matrix:

  System               | Partition   | Else
  ─────────────────────┼─────────────┼──────────────
  Cassandra (default)  | PA          | EL
  Cassandra (QUORUM)   | PC          | EC
  etcd                 | PC          | EC
  ZooKeeper            | PC          | EC
  DynamoDB (eventual)  | PA          | EL
  DynamoDB (strong)    | PC          | EC
  MySQL async replica  | PA          | EL
  MySQL sync replica   | PC          | EC
  Spanner              | PC          | EC (bounded)
  CouchDB              | PA          | EL

Latency cost of consistency (example):

  EL path: client → primary → ack                = ~1ms RTT
  EC path: client → primary → replicas → ack    = ~5-15ms RTT
                                                   (3× to 15× slower)

The tradeoff is always present; PACELC makes it explicit.

When to Reach for This

  • When choosing between consistency levels on a per-request basis (e.g., DynamoDB eventually consistent vs. strongly consistent reads — knowing you pay 2× latency for strong consistency)
  • When setting Cassandra replication factor and consistency level (ONE vs. QUORUM vs. ALL) — each position on the L↔C spectrum has a latency and fault-tolerance cost
  • When designing multi-region writes: cross-region coordination costs 50-200ms of additional latency per write; PACELC makes this tradeoff quantifiable
  • When a team argues about whether to use async or sync database replication — framing as EL vs. EC clarifies that both sides are giving up something real
  • When auditing a system's consistency guarantees for a compliance or correctness requirement: the PACELC class determines what can go wrong during normal operations, not just failures

When NOT to Use This

  • For single-replica or single-node systems: without replication there is no coordination cost and the L↔C tradeoff doesn't apply
  • When latency requirements are loose enough that the EC path is fine: if your SLO is 1s and EC costs 15ms, the distinction between EL and EC is operationally irrelevant — CAP is sufficient framing
  • As a substitute for measuring actual latency impact: PACELC tells you the direction of the tradeoff but not the magnitude; measure replication acknowledgement latency in your specific environment before deciding

Applied Examples

Example 1: Cassandra Consistency Level Selection for an API

A user profile service reads from Cassandra and must return a response within 50ms at p99. The Cassandra cluster has a replication factor of 3 across 3 availability zones.

PACELC analysis of each consistency level: - ONE (EL): read from any one replica. Latency: ~2ms. Risk: stale reads if the replica lags. Classification: PA/EL. - QUORUM (EC): read from 2 of 3 replicas, return the most recent. Latency: ~8ms (bounded by second-fastest replica). Guarantees: no stale reads for data written at QUORUM. Classification: PC/EC. - ALL: read from all 3 replicas. Latency: ~15ms (bounded by slowest). Classification: PC/EC, maximum consistency.

For user profiles (stale reads are tolerable — showing a slightly outdated profile picture is not critical), the team chooses QUORUM for writes (to prevent data loss) and ONE for reads (low latency). This is a deliberate PA/EL choice for reads with PC/EC for writes — a common and sensible hybrid.

For payment balances (stale reads are a correctness issue — a user might overdraft), the team uses QUORUM for both reads and writes. The 8ms latency cost is acceptable given the 50ms budget and the correctness requirement.

Example 2: Multi-Region Write Tradeoff

A SaaS platform is expanding to serve users in both US and EU. Orders must be written durably before confirming to the user. The question: synchronous multi-region writes or async replication?

PACELC framing: - Async replication (PA/EL): write to US primary, return success, replicate to EU asynchronously. Latency added: ~0ms. Risk during partition: EU replica is stale; a US failure during replication loses the order. - Synchronous multi-region write (PC/EC): write to US, wait for EU acknowledgement before returning. Latency added: 80-120ms (US↔EU RTT). During a partition: writes are rejected until connectivity restores.

For orders, losing data (PA/EL) is unacceptable. The team chooses synchronous writes (PC/EC), accepting 100ms additional latency. They surface this to product as a design constraint: EU-routed users will have higher checkout latency, and during a transatlantic network event, checkout will be unavailable rather than silently losing orders.

This decision is documented explicitly so future engineers know the latency cost is a deliberate consistency guarantee, not a performance bug.

The Junior vs Senior Gap

Junior Senior
Asks "which database is faster?" without specifying what consistency level they need Asks "what consistency does this data require?" and then evaluates what latency cost that consistency level imposes
Treats "eventual consistency" as a setting to enable for performance and forgets about it Defines the acceptable staleness window (seconds? minutes?) and designs conflict resolution for when replicas diverge
Unaware that DynamoDB strongly consistent reads cost 2× the read capacity units of eventually consistent reads Profiles per-request cost and latency of each consistency mode and chooses explicitly per endpoint
Views async replication as "the fast version" of sync replication Understands async replication as a durability tradeoff: you are betting that the primary will not fail before the replica syncs

Connections

  • Complements: CAP Theorem — PACELC extends CAP by adding the normal-operation (no partition) latency-vs-consistency tradeoff; use CAP for partition behavior, PACELC for complete operational design
  • Complements: Queueing Theory — the latency cost of consistency (waiting for replica acknowledgements) adds to W in Little's Law, increasing concurrency requirements; high-consistency systems need larger connection pools
  • Tensions: Graceful Degradation — PC systems degrade by becoming unavailable during partitions; graceful degradation patterns (serving stale cache, returning partial results) effectively shift a PC system toward PA behavior at the application layer
  • Topic Packs: distributed-systems