CAP theorem is a distributed-systems principle that says a system facing a network partition cannot guarantee both consistent data and an available response for every request. It helps engineers decide whether an application should reject or delay requests to protect correctness, or continue responding with data that may be temporarily outdated. Despite the common "pick two of three" shorthand, the trade-off matters specifically when communication between system nodes breaks down.
CAP theorem
What Is the CAP Theorem?
CAP theorem, also called Brewer's theorem, describes a limit in distributed data systems. When a network partition prevents servers from communicating, a system cannot guarantee both consistent data and an available response for every request. "Pick two of three" is shorthand: the key trade-off occurs when nodes cannot communicate.
Consistency, Availability, and Partition Tolerance Explained
CAP uses meanings that differ from everyday use.
| Property | Meaning in CAP |
|---|---|
| Consistency | Every read receives the latest successful write, or an error. It does not simply mean data is valid or well formatted. |
| Availability | Every request received by a non-failing node gets a response, which may contain older data. |
| Partition tolerance | The system keeps operating despite lost or delayed messages between nodes, such as cloud regions. |
How CAP Theorem Trade-Offs Work During a Network Partition
Consider an inventory service replicated across two regions. A connection failure separates them while customers place orders.
- A customer buys the last item, and the write reaches the first region.
- The second region cannot receive the update because replication is blocked.
- A CP design rejects or waits on an order at the second region to avoid a sale based on stale inventory.
- An AP design answers from the second region, even if it shows the item as available until reconnection.
CP, AP, and CA Systems Compared
The right behavior depends on the harm caused by a rejected request versus stale data.
| Approach | Behavior during a partition | Typical fit |
|---|---|---|
| CP | May reject, delay, or limit requests to preserve one current data version. | Payments, reservations, and account balances. |
| AP | Continues responding, then reconciles divergent data after recovery. | Feeds, catalogs, and telemetry where brief staleness is acceptable. |
| CA | Assumes partitions do not occur, so it cannot provide both guarantees during one. | Single-node or tightly controlled deployments, not fault-tolerant multi-node systems. |
Why Engineers Use CAP Theorem
CAP is a failure-behavior framework, not a database product label.
- It makes teams define how reads and writes behave when dependencies cannot communicate.
- It helps explain whether users may see an error, delay, or outdated information.
- It encourages testing blocked connections, delayed replication, and partial failures.
Practical Limits of CAP Theorem
CAP answers one narrow question: what happens during a partition.
- It does not measure normal latency, throughput, cost, or security.
- It does not permanently classify systems as CP or AP, because behavior can vary by operation and configuration.
- It is not limited to NoSQL databases. Any replicated distributed service faces the trade-off.
- Eventual consistency means replicas may converge later. For non-partition decisions, PACELC adds a latency-versus-consistency lens.
Applying CAP Decisions When Building with Emergent
Apps built with an AI app builder can depend on replicated databases, APIs, queues, and multi-region services. When creating an AI web app with Emergent, define which actions need current data, which can tolerate brief staleness, and how the interface explains retries or unavailable actions. Build resilient distributed apps with Emergent.
Start Building
on Emergent today
on Emergent today
Start Building
