CAP Theorem Cheat Sheet

Explains Consistency, Availability, and Partition tolerance trade-offs in distributed databases and how real systems position themselves on the CAP spectrum.

1 PageIntermediateFeb 28, 2026

CAP Theorem Definitions

The three properties the theorem trades off.

Consistency (C)- Every read receives the most recent write or an error; all nodes see the same data at the same time
Availability (A)- Every request receives a (non-error) response, without guarantee it contains the most recent write
Partition tolerance (P)- The system continues operating despite network failures that drop or delay messages between nodes
The theorem- During a network partition, a distributed system must choose between Consistency and Availability — it cannot guarantee both
P is not optional- Network partitions will happen in any real distributed system, so practically the choice is always CP vs AP, not whether to have P

CP vs AP in Practice

How real database systems position themselves.

CP systems- Prioritize consistency during a partition, may reject requests or return errors rather than stale/conflicting data (e.g., HBase, MongoDB with majority read/write concern, ZooKeeper, etcd)
AP systems- Prioritize availability during a partition, may return stale data rather than an error (e.g., Cassandra, DynamoDB, Riak with eventual consistency settings)
Tunable consistency- Many modern systems (Cassandra, DynamoDB) let you choose consistency level per-query (e.g., QUORUM, ONE, ALL) rather than being fixed CP or AP
Single-node / no partition- CAP only applies to distributed systems facing an actual partition; a single-node relational database is trivially both C and A absent a network split

Partition Scenario

How CP and AP systems respond when a node is cut off.

bash

# Cluster of 3 nodes (A, B, C) replicating a key "balance"# Network partition splits A | B,C# CP choice: node A refuses writes/reads (or returns an error)# because it cannot confirm it has the latest value with quorumcurl -X PUT nodeA/balance -d '100'   # -> 503 Service Unavailable# AP choice: node A accepts the write locally and will# reconcile/merge with B,C once the partition healscurl -X PUT nodeA/balance -d '100'   # -> 200 OK (may conflict later)# On healing, AP systems reconcile via last-write-wins,# vector clocks, or CRDTs depending on the database

Beyond CAP: PACELC

A refinement that accounts for latency even without a partition.

PACELC extension- If Partitioned, choose between Availability and Consistency (as in CAP); Else (no partition), choose between Latency and Consistency
Why it matters- CAP only describes partition behavior; PACELC acknowledges that even without a partition, synchronous replication for consistency adds latency
Example- DynamoDB is PA/EL (favors availability during a partition, low latency normally); Postgres with synchronous replication is PC/EC (favors consistency both times)

Pro Tip

Don't treat CAP as a permanent label on a database product — most real systems let you tune the trade-off per operation (e.g., DynamoDB's eventually-consistent vs strongly-consistent reads, Cassandra's consistency levels), so the real design decision is per-query, not per-database.

Was this cheat sheet helpful?

Data Modeling Best Practices Cheat Sheet

Database Locking & Concurrency Cheat Sheet

Explore Topics

#CAPTheorem#CAPTheoremCheatSheet#Database#Intermediate#CAPTheoremDefinitions#PartitionScenario#BeyondCAPPACELC#Explains#Databases#CheatSheet#SkillVeris

Sri Hayavadhana Info-Tech

Professional Web Designing Services