PACELC

Daniel Abadi’s 2010 (blog) / 2012 (paper) extension of cap-theorem|CAP that adds the latency dimension CAP omits.

If Partition, choose between Availability and Consistency. Else (normal operation), choose between Latency and Consistency.

The first half restates CAP. The second half is the addition: even when the network is fine, there is always a tradeoff between how fast you respond and how confident you are in the freshness of the data.

Why this matters

The vast majority of the time, your network is healthy — yet every replication-related dial you turn is implicitly a latency-vs-consistency decision:

• DynamoDB: strongly-consistent reads cost 2× capacity units and are slower than eventually-consistent reads. Amazon literally prices consistency as a line item.
• Cassandra: per-query consistency levels (ONE / QUORUM / ALL) — every choice trades latency for staleness bounds.
• MongoDB: read preferences (primary / primaryPreferred / secondaryPreferred / nearest).
• Postgres / MySQL replicas: sync vs async replication.

If you’ve ever tuned any of these, you’ve made a PACELC decision — probably without naming it.

How a partition actually arises

A partition is not a separate failure category — it’s a timeout with a name. Node A writes, sends a confirm request to Node B, waits. Node B is slow (load? congestion? real failure?). At some point Node A must:

• Cancel and proceed without confirmation → consistency at risk.
• Keep waiting → availability suffers (waiting indefinitely is just choosing consistency with infinite latency).

You don’t detect partitions — you define them by your timeout. That makes PACELC’s “else” branch a continuum, not a binary.

Mnemonic for systems

System	Partition: PA / PC	Normal: EL / EC
DynamoDB (default)	PA	EL
Cassandra (default)	PA	EL
MongoDB (default)	PC	EC
PNUTS	PA	EL
BigTable / HBase	PC	EC
VoltDB / H-Store	PC	EC

(Quoted from Abadi’s paper; exact behavior depends on configuration.)

See also

• cap-theorem — the original framework PACELC extends
• partition-mode-design — what to do once you’ve named your tradeoff
• crdt — eliminate consistency-vs-latency for certain data types
• local-first-software — push everything to EL by serving locally