> For the complete documentation index, see [llms.txt](https://kdongs.gitbook.io/kdocs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kdongs.gitbook.io/kdocs/cap-theorem/cap-theorem.md).

# CAP Theorem

## About

The CAP Theorem states that you cannot have a system that is **Partitioned** (redundant/partition tolerance), **Consistent** (linearizability[^1]) and **Available**.

<table data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Consistency</strong></td><td>Every read receives the most recent successful write, or an error.<br><br>- If client A writes <code>x=5</code>;<br>- Client B reads <code>x</code>;<br>- B must see <code>5</code>, not <code>4</code>;</td></tr><tr><td><strong>Availability</strong></td><td>Every request receives a non-error response, even if it is <strong>stale</strong>.<br><br>- The system must respond;<br>- It cannot say "sorry, try later";<br>- But the response does not need to be correct (eventual consistency);</td></tr><tr><td><strong>Partition Tolerance</strong></td><td>The system continues to operate despite network partitions.<br><br>- Messages may be delayed, dropped, or reordered;<br>- Nodes cannot reliably communicate</td></tr></tbody></table>

### The choices

You can only guarantee at most two of these three properties.

If:

* You use more than one node;
* Over a network;
* And don't control the network perfectly;

You have already have **P** (distributed systems).

So the choice is, during a partition, do I prefer to be:

* wrong (AP), opting for availability, or
* unavailable (CP), opting for consistency;

If:

* Single node, or
* Perfect network (highly improbable)

Then you can be consistent and available (AC).

<table><thead><tr><th width="128">Type</th><th>Description</th></tr></thead><tbody><tr><td>AC</td><td>Without partitioning, the data are consistent and available.</td></tr><tr><td>AP</td><td>With partitioning, if you opt by availability, you lose consistency.</td></tr><tr><td>CP</td><td>With partitioning, if you opt by consistency, you lose availability.</td></tr></tbody></table>

### Why use it

Distributed systems fail in ways local systems don't, and CAP defines the failure behavior.

CAP forces you to answer:

> When the network breaks, what do I sacrifice?

And the answer **must be intentional, not accidental**.

### How to use it

In system design you use CAP by identifying failure scenarios.

> What happens if:
>
> * Node A cannot reach Node B?
> * Half the cluster is unreachable?
> * Leader is isolated?
> * ...

And by classifying data by business semantics. **Not all data needs the same CAP behavior**.

| Type            | CAP preference           |
| --------------- | ------------------------ |
| Payments        | CP (needs consistency)   |
| Auth tokens     | CP (needs consistency)   |
| Inventory count | CP or hybrid             |
| User profile    | AP (better availability) |
| Metrics/logs    | AP (better availability) |

#### Tunable consistency (Dynamo model)

Systems like Cassandra allow:

* `R` read quorum;
* `W` write quorum;
* `N` replication factor;

$$R +W > N \longrightarrow Strong\ consistency$$

$$R + W \le N \longrightarrow Eventual\ consistency$$

You are **explicitly trading C vs A** per request.

[^1]: A strong consistency model for concurrent systems, making them appear as if there is a single, non-replicated data copy where operations happen instantaneously and atomically.