CAP Theorem

A fiber cut between us-east-1a and us-east-1b just isolated half your database cluster from the other half. Both halves are alive; both can serve traffic; neither can talk to the other. Right now your inventory service is being asked: “Is this product in stock?” — and both sides have to answer something. Do you return potentially stale stock counts (and risk overselling) or refuse the request entirely (and lose the sale)? There is no third option — and that is the heart of the CAP theorem. It forces every distributed system to declare, in advance, what it does when the network breaks.

The CAP theorem states that a distributed system can satisfy at most two of three properties simultaneously: Consistency, Availability, and Partition Tolerance. During a network partition, you must choose between consistency and availability — you cannot have both.

The Three Properties

Consistency (C)

Every read returns the most recent write or an error. All nodes see the same data at the same time.

This is linearizability in CAP terms — the system behaves as if there is one copy of the data, and every operation takes effect atomically at some point between its start and completion. It is not the same as eventual consistency.

Node A  ──── write x=2 ────►  Node A: x=2
                               Node B: x=2   ← must reflect the write immediately
                               Node C: x=2

Any read from any node must return x=2 after the write commits.
A read returning x=1 (old value) is a consistency violation.

Availability (A)

Every request to a non-failing node receives a response — not an error, not a timeout. The response does not need to contain the most recent data; it just cannot be an error.

Key nuance: A system is available in the CAP sense even if it returns stale data, as long as it responds. A system that returns “503 Service Unavailable” or times out during a partition is not available.

Partition Tolerance (P)

The system continues operating even when the network drops or delays messages between nodes. Nodes cannot communicate with each other during a partition, but the system keeps running.

Partition tolerance is not optional. Networks fail. Links go down. Switches lose packets. In any real distributed system deployed across multiple machines or datacenters, you must assume partitions will occur. P is not a choice — it is a requirement of being distributed.

This means the real choice is: CP or AP.

Why You Can’t Have All Three During a Partition

When a partition occurs, two nodes cannot communicate. A write has been applied to Node A but not yet to Node B.

sequenceDiagram
    participant C1 as Client 1
    participant A as Node A
    participant B as Node B
    participant C2 as Client 2

    Note over A,B: ✗ Network partition — A and B cannot communicate

    C1->>A: write x = 2
    A->>A: x = 2 (stored locally)
    A->>C1: write ACK

    Note over B: B still has x = 1 (old value)

    C2->>B: read x

    alt CP — choose Consistency
        B->>C2: ERROR (cannot confirm latest value — sacrifices Availability)
    else AP — choose Availability
        B->>C2: x = 1 (stale — sacrifices Consistency)
    end

The impossibility is simple: Node B cannot return x = 2 because the partition prevents it from receiving the write. It has two choices:

1. Refuse the read (CP) — returns an error or blocks until the partition heals. The system remains consistent but gives up availability.
2. Return stale data (AP) — responds immediately with x = 1. The system remains available but serves an inconsistent response.

There is no third option. You cannot conjure the value x = 2 on Node B without receiving it from Node A.

CP Systems

CP systems choose consistency over availability during a partition. The mechanism is always the same: a write must reach a majority (quorum) before it commits. A node that cannot reach a quorum refuses requests rather than risk serving stale data, until the partition heals.

5-node cluster, partition splits into [3, 2]:
  Majority side (3 nodes): can form quorum → serves reads and writes
  Minority side (2 nodes): cannot form quorum → refuses all requests

After the partition heals, all nodes converge on the same state.

You’ll see this in coordination and metadata stores, where handing out stale data (a wrong leader address, a deleted config) is worse than briefly refusing requests:

AP Systems

AP systems choose availability over consistency during a partition. Every node keeps accepting reads and writes, so partitions may diverge; after the partition heals, the system reconciles the conflicting versions. Two ideas matter more than any product:

• Tunable consistency — the CP/AP label isn’t fixed. A quorum-based store behaves as AP when it answers from a single replica (fast, maybe stale) and as CP when it requires a majority (refuse rather than serve stale). The same cluster sits on different sides of CAP depending on the per-operation setting.
• Reconciliation on reconnect — because both sides accepted writes, the system must merge them: last-write-wins by timestamp, version/vector clocks to detect concurrent writes, or CRDTs where any merge order is correct. Availability during the partition is paid for with reconciliation complexity after it.

System Classification

Common Misconceptions

“You pick 2 of 3.” The framing implies P is optional — it isn’t. Any system spanning multiple machines must tolerate partitions, so the real choice is CP or AP when one occurs. With no partition, a system can satisfy all three at once.

“CA systems exist.” CA only describes a single node, which has no partition to tolerate. “MySQL is CA” means single-node MySQL; the moment you add a replica, the primary–replica link can partition and you must choose CP or AP.

“CAP-C = ACID-C.” CAP’s C is linearizability (every read reflects the latest write globally); ACID’s C is invariant preservation (constraints hold within a transaction). A system can be ACID-consistent on one node while returning stale cross-node reads during a partition.

“Cassandra is always AP.” At ALL (or QUORUM when a partition drops below quorum) it refuses the operation rather than serve stale data — CP behavior. The label depends on the configured consistency level, not the product.

CAP in Practice

The binary CP/AP framing is a simplification. Real systems are more nuanced:

The PACELC model extends CAP to describe the latency vs. consistency tradeoff that exists even in the absence of partitions — which is the more common operating condition.

Test Your Understanding