CAP & PACELC

The CAP theorem is one of the most cited results in distributed systems. It states that any distributed data store can provide at most two of the following three properties: Consistency, Availability, and Partition tolerance. In practice, because networks are unreliable, partition tolerance is not optional — so the real tradeoff is between consistency and availability.

PACELC extends CAP by recognizing that even when there is no partition, there is a tradeoff between Latency and Consistency. Together, CAP and PACELC provide a useful vocabulary for reasoning about distributed database design.

This guide explains the theorem clearly, debunks common misconceptions, and shows how real systems make these tradeoffs every day.

CAP uses three properties with specific technical meanings. It is important not to confuse colloquial usage with the theorem's definitions.

A network partition occurs when nodes cannot communicate with each other. Partitions are inevitable: switches fail, packets are dropped, regions lose connectivity, and GC pauses delay heartbeats. A system that is not partition-tolerant would halt whenever the network hiccups, making it unsuitable for real distributed deployments.

CP systems choose consistency over availability during a partition. They refuse requests or block until the partition heals to avoid serving stale data. AP systems choose availability over consistency during a partition. They continue serving reads and writes, accepting that replicas may diverge temporarily.

PACELC, proposed by Daniel Abadi, extends CAP with the observation that even when there is no partition, there is a tradeoff between Latency and Consistency. The acronym reads: "If there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency."

Consistency is not binary. There is a spectrum from strong to weak, each with different guarantees and costs. Choosing the right model depends on what correctness means for your application.

The CAP/PACELC framework is most useful when applied to concrete design decisions. Here are common scenarios and the consistency choices that make sense.

Modern distributed databases rarely force a global CP or AP choice. Instead, they expose tunable consistency levels per operation. Understanding these knobs lets you optimize for latency and correctness without changing databases.