PACELC
An extension of CAP that also describes the normal case — if Partitioned choose Availability or Consistency, Else choose Latency or Consistency.
CAP describes only what happens during a partition, which is a rare event. PACELC, proposed by Daniel Abadi, adds the clause that covers the other 99.9% of the time.
Read as two independent choices, which is what makes it useful for classifying real systems:
| System | Partition | Normal operation |
|---|---|---|
| DynamoDB (eventually consistent reads) | PA | EL — favours latency |
| Cassandra (default tuning) | PA | EL |
| Spanner | PC | EC — pays latency for consistency |
| MongoDB (majority writes) | PC | EC |
| PostgreSQL with sync replication | PC | EC |
The second half is the one that decides day-to-day behaviour. A system that is "CP" tells you nothing about whether every read costs a quorum round trip — and that cost is what you feel on every request, forever, whereas the partition behaviour matters for minutes a year.
The design question PACELC forces: what latency am I willing to pay on every single operation to avoid a stale read? Ask it per operation, not per system.