CAP Theorem Explained
The CAP theorem states that when a distributed system is partitioned, it cannot guarantee both linearizable consistency and availability for every request. Consistency means operations appear to use one up-to-date copy; availability means every request to a non-failing node eventually receives a non-error response. Partition tolerance means the model allows messages between groups of nodes to be lost or delayed. For how strong vs eventual models behave outside partitions, see Strong vs Eventual Consistency; for quorum math, see Quorum Reads and Writes.
This is not a fixed logo taxonomy. MongoDB, Cassandra, Dynamo-style stores, and replicated PostgreSQL can expose different behavior depending on topology, read/write concerns, quorum settings, failover, and request path. A single-node database has no inter-node partition to classify under CAP; once data or coordination spans nodes, the partition trade-off becomes concrete.
Consistency, Availability, and Partition Tolerance
Consistency in CAP means linearizability — after a write completes, every subsequent read from any node returns that value. This is stronger than eventual consistency, where replicas may temporarily disagree. Availability means every non-failing node returns a response in a reasonable time — no timeouts, no errors due to the partition itself. Partition tolerance means the system continues operating when network links between nodes break.
In practice, partition tolerance is not optional for distributed systems. Networks fail, switches reboot, and availability zones go down. So the real trade-off is CP vs AP: during a partition, do you reject requests to preserve consistency, or accept them and reconcile later?
Quick reference
- Consistency (CAP): linearizability — after a write completes, later reads return that value; not ACID "consistency."
- Availability: every request to a non-failing node gets a response — no guarantee it is the latest data.
- Partition tolerance: system operates despite arbitrary message loss between nodes.
- Network partitions are inevitable in distributed systems — design for them, do not assume they won't happen.
- PACELC extends CAP: if Partition, choose A or C; Else, choose Latency or Consistency.
Remember this
Partition tolerance is mandatory in distributed systems — the real choice is consistency vs availability during a split.
CP Systems (Consistency + Partition Tolerance)
CP designs prioritize linearizable consistency over CAP availability during a partition. A side that cannot establish the required leader or quorum rejects operations whose safety it cannot prove rather than acknowledging conflicting state. Consensus-backed stores such as etcd and ZooKeeper are common examples; MongoDB can show CP-like behavior for operations configured with suitable read/write concerns and topology.
The cost is availability for affected operations. Clients unable to reach the required quorum see failures or timeouts. For a ledger or inventory lock, that may be the correct trade. Pair this design with bounded retries and clear errors so callers know the operation was not accepted.
Quick reference
- Under partition: most recent write or error — never a silent stale success.
- Examples depend on configuration; consensus stores and quorum-configured operations commonly choose consistency.
- Minority partition rejects writes to prevent split-brain.
- Best for: financial transactions, inventory, config stores, leader election.
- Use quorum writes so a majority must acknowledge before success.
- Clients need retry logic — CP errors during partitions are expected.
Remember this
In CP, a partition means latest-known write or an error — not a guessed value.
AP Systems (Availability + Partition Tolerance)
AP designs preserve CAP availability for requests that reach a non-failing replica during a partition, so reachable sides may continue serving operations even when they cannot coordinate. Returned data can be stale, and whether each side accepts a particular read or write still depends on consistency level, quorum, topology, and product configuration. Cassandra and Dynamo-style systems can be configured toward this behavior; they are not permanently AP under every request mode.
The cost is linearizable consistency. A user may read stale state or concurrent writes may need reconciliation. That can fit feeds, carts, and counters but is dangerous for ledgers. Use idempotent writes and explicit conflict rules; storage-level reconciliation does not understand business meaning.
Quick reference
- Under partition: reachable replicas can remain available for operations allowed by the configured consistency level.
- Examples are configuration-dependent: Cassandra and Dynamo-style stores can favor availability.
- Multiple sides may accept operations and diverge temporarily when quorum rules permit.
- Best for: social feeds, shopping carts, analytics, session stores.
- Tune consistency when needed (e.g. Cassandra QUORUM) without leaving AP defaults blindly.
- Plan conflict resolution: last-write-wins, CRDTs, or app-level merge.
Remember this
In AP, reachable replicas preserve non-error responses for allowed operations, accepting possible staleness or conflict.
CA Systems and the Real World
“CA” is often drawn as the third corner, but it is not a useful CAP classification for a single-node database: with no inter-node communication, there is no network partition in the theorem's model. A standalone PostgreSQL or MySQL instance can provide transactional consistency while it is reachable, but it can still crash or become unavailable.
Once replication or coordination spans nodes, behavior depends on the operation and configuration. Synchronous PostgreSQL commits may block or fail without the required standbys; asynchronous replicas may serve stale reads; DynamoDB offers request-specific consistency options with regional constraints. CAP is a partition-time lens, not a permanent product label.
Quick reference
- Single-node databases sit outside CAP's inter-node partition trade-off rather than forming a useful “CA” category.
- Adding read replicas introduces eventual consistency for reads.
- Multi-node designs must specify which operations remain available and consistent during a partition.
- DynamoDB: strong consistency per request or eventual (default).
- Design for the failure mode you cannot tolerate — not the one that is easiest to implement.
Remember this
A single node has no inter-node CAP partition; distributed topologies must define behavior per operation and failure.
Key takeaway
CAP is a decision lens for partitions: a consistency-favoring operation may reject work it cannot safely coordinate; an availability-favoring operation may return stale data or accept conflicting writes. Product behavior follows topology and request settings, not a permanent CP/AP sticker. In design reviews, name the business cost of stale data versus rejected work.
Practice (15 min): For “checkout inventory” vs “like counter,” state the topology, quorum or consistency setting, and expected read/write result on each side of a split. If you cannot predict which operations fail or become stale, the design is not specified yet.
Related Articles
Explore this topic