The CAP Theorem is a foundational principle in distributed systems stating that a distributed data store can guarantee at most two of three properties — Consistency, Availability, and Partition Tolerance — simultaneously. Understanding CAP helps engineers make informed trade-offs when designing or choosing distributed databases and services.
Proposed by Eric Brewer in 2000 and formally proved by Gilbert and Lynch in 2002, the CAP Theorem states that no distributed system can simultaneously guarantee Consistency (C), Availability (A), and Partition Tolerance (P). Consistency means every read receives the most recent write or an error. Availability means every request receives a non-error response, though it may not be the latest data. Partition Tolerance means the system continues operating even when network messages between nodes are dropped or delayed.
In any real-world distributed system, network partitions — temporary communication failures between nodes — are inevitable. Because you cannot eliminate partitions, you must always tolerate them, making the real choice a trade-off between Consistency and Availability during a partition event. This reduces CAP in practice to a choice between CP (consistent but potentially unavailable) and AP (available but potentially inconsistent) systems.
CP systems prioritize returning correct, consistent data and will refuse to respond or return an error if a partition prevents them from guaranteeing that. HBase, Zookeeper, and etcd are classic CP systems used in scenarios where stale data is unacceptable, such as financial ledgers or leader election. During a partition, a CP system may become temporarily unavailable to preserve data correctness.
AP systems prioritize responding to every request even during a partition, accepting that some nodes may return stale or divergent data. Cassandra, CouchDB, and DynamoDB (in default mode) follow the AP model, making them well-suited for use cases like shopping carts, social feeds, or DNS where high availability matters more than strict correctness. These systems typically implement eventual consistency, meaning all nodes will converge to the same state once the partition heals.
The CAP Theorem only describes trade-offs during a partition, but the PACELC model extends this by asking: even when the system is running normally (Else), must you trade Latency (L) for Consistency (C)? This highlights that even without a partition, replicating writes to multiple nodes takes time, creating a latency vs. consistency trade-off. PACELC gives a more complete picture of distributed system design in everyday operation.
CAP is a simplification — real systems exist on a spectrum and often allow tunable consistency levels per operation, as seen in Cassandra's quorum settings. Avoid treating CAP as a rigid checklist; instead, identify your application's specific consistency and availability requirements per use case. Always test partition-failure scenarios explicitly in staging, because the trade-offs you chose on paper will only reveal their true impact under real network failure conditions.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app