[Avg. reading time: 6 minutes]

PACELC

The PACELC theorem is indeed a direct extension of the CAP theorem.

If Partition exists choose between Availability or Consistency Else Latency or Consistency

What If Partition Exists (P) means

  • A network partition has occurred
  • Some nodes cannot communicate with others
  • Messages are dropped, not just delayed

When CAP exists why PACELC?

CAP focuses exclusively on what happens during a network failure (a “partition”), PACELC addresses a major critique: it accounts for how a system behaves during normal, healthy operation.

  • Most systems run without network partitions most of the time
  • Datacenters are engineered to avoid partitions
  • Partitions are rare but catastrophic
  • So when everything works, you still trade consistency vs latency.
                Distributed System
                        |
                        v
             Is there a network partition?
                        |
            +-----------+-----------+
            |                       |
          YES (P)                NO (ELSE)
            |                       |
            v                       v
   Availability (A)         Low Latency (L)
            |                       |
   - Keep serving            - Read nearest replica
   - May return              - Async replication
     inconsistent data       - Possible staleness
            |
            |
            v
     Consistency (C)         Consistency (C)
            |                       |
   - Block / error           - Quorum / consensus
   - Wait for quorum         - Higher latency
   - Data always correct     - Strong guarantees
DatabaseP: Availability vs ConsistencyELSE: Latency vs ConsistencyPACELC ClassNotes
CassandraAvailabilityLatencyPA / ELAlways-on design, async replication, eventual consistency
DynamoDBAvailabilityLatencyPA / ELDynamo-style, low latency reads, consistency is optional
RiakAvailabilityLatencyPA / ELConflict resolution after the fact
CouchDBAvailabilityLatencyPA / ELMulti-master replication, conflicts expected
MongoDB (Replica Set)ConsistencyConsistencyPC / ECPrimary-based writes, blocks during elections
HBaseConsistencyConsistencyPC / ECStrong consistency via HDFS, higher coordination cost
Google SpannerConsistencyConsistencyPC / ECGlobal consensus, correctness over latency
CockroachDBConsistencyConsistencyPC / ECDistributed SQL, serializable isolation
ElasticsearchAvailabilityLatencyPA / ELSearch-first, stale reads acceptable
Redis ClusterAvailabilityLatencyPA / ELSpeed first, eventual consistency under failure
Last change: 2026-03-03