100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Database

CAP Theorem

IntermediateConcept1.5K learners

The CAP theorem states that a distributed data system can provide at most two of three guarantees simultaneously during a network partition: Consistency, Availability, and Partition Tolerance.

Definition

The CAP theorem states that a distributed data system can provide at most two of three guarantees simultaneously during a network partition: Consistency, Availability, and Partition Tolerance.

Overview

Formulated by Eric Brewer and later formally proven, CAP theorem describes a hard trade-off distributed databases face specifically when a network partition occurs — that is, when some nodes in a cluster cannot communicate with others. Consistency here means every read receives the most recent write or an error; Availability means every request receives a non-error response, even if it isn't the most recent data; Partition Tolerance means the system continues operating despite dropped or delayed messages between nodes. Because network partitions are an unavoidable reality in any real distributed system, partition tolerance is effectively mandatory, which means the practical choice most systems face is really between consistency and availability when a partition occurs. Systems that choose consistency over availability during a partition (CP systems) will refuse to serve potentially stale reads or writes on the minority side of a partition until connectivity is restored — traditional relational databases running in a distributed configuration, and systems like HBase, tend toward this behavior. Systems that choose availability over consistency (AP systems) keep serving requests on both sides of a partition, accepting that data may temporarily diverge and need to be reconciled afterward — early Amazon DynamoDB and Apache Cassandra are classic examples, favoring ACID properties-style guarantees be relaxed in favor of uptime. CAP theorem is frequently misunderstood as forcing an all-or-nothing choice across an entire system; in practice, many databases let operators tune the trade-off per-operation (e.g., adjustable read/write quorum levels in Cassandra), and the theorem only strictly applies during an actual partition — most of the time, when the network is healthy, a system can provide both consistency and availability. It remains a foundational mental model for reasoning about distributed database design, sharding, and database replication strategies.

Key Concepts

  • Describes a trade-off among Consistency, Availability, and Partition Tolerance
  • Applies specifically to behavior during an active network partition
  • Partition tolerance is effectively non-negotiable in real distributed systems
  • CP systems sacrifice availability to preserve strict consistency during partitions
  • AP systems sacrifice strict consistency to remain available during partitions
  • Many databases allow tunable consistency levels rather than a fixed CAP stance
  • Closely tied to distributed sharding and replication strategy decisions

Use Cases

Choosing a database's consistency model for a distributed application
Reasoning about behavior when nodes in a cluster lose connectivity
Evaluating trade-offs between DynamoDB-style AP systems and CP relational clusters
Designing quorum-based read/write configurations in distributed databases
Teaching foundational distributed-systems trade-offs in database courses

Frequently Asked Questions