# PACELC

> CAP covers partitions; PACELC adds the latency-versus-consistency trade-off the rest of the time.

Concept · Consistency & coordination · https://levelcode.org/concepts/pacelc

PACELC extends the [CAP theorem](https://levelcode.org/concepts/cap-theorem) to cover the normal case:

> If there's a **P**artition, choose **A**vailability or **C**onsistency; **E**lse (no partition), choose **L**atency or **C**onsistency.

## Why the "else" matters

Partitions are rare. The trade-off you make on **every** request is latency: to be strongly consistent, a write must reach a quorum or a leader and a read must confirm it sees the latest value, which costs round trips — and across regions, tens to hundreds of milliseconds each.

## Classifying systems

| System | During a partition | Otherwise |
|---|---|---|
| Spanner, CockroachDB, etcd | Consistency (PC) | Consistency (EC) — pay the latency |
| Cassandra, DynamoDB (defaults) | Availability (PA) | Latency (EL) — reads may be stale |
| PostgreSQL primary + async replicas | Consistency on the primary | Latency when reading replicas |
| MongoDB (majority read/write concerns) | Consistency (PC) | Consistency (EC) |

Many systems are tunable per request, so the classification describes defaults rather than fixed properties.

## Using it in design

Ask two questions for each operation:

1. If the network splits, should this keep working with possibly stale data, or refuse?
2. Is the latency of a consistent read or write acceptable on the normal path?

A shopping cart might answer "keep working" and "favour latency"; a funds transfer "refuse" and "pay the latency". See [consistency models](https://levelcode.org/concepts/consistency-models).