TopolearnCAP is the vocabulary used to describe every distributed database's behaviour under failure.
The CAP theorem concerns a data store replicated across nodes. Of three properties it can't guarantee all at once when the network fails:
- Consistency (here meaning linearizability): every read sees the most recent write.
- Availability: every request to a working node gets a non-error response.
- Partition tolerance: the system keeps operating when messages between nodes are lost.
Network partitions will happen, so P isn't optional. The real choice is what to do during a partition: refuse some requests to stay consistent (CP: e.g. a single-leader database where the side without the leader rejects writes, or etcd/ZooKeeper) or keep answering on both sides and reconcile later (AP: e.g. Cassandra or DynamoDB in their default eventually consistent modes).
CAP is often oversimplified. It says nothing about the normal case, and real systems offer tunable choices per request (quorum reads, strongly consistent reads). PACELC fills the gap: if Partitioned, choose A or C; Else, choose Latency or Consistency. Even without failures, waiting for replicas to agree costs latency, so many systems pick lower latency and weaker consistency in normal operation too.
When evaluating a database, ask concretely: what happens to writes and reads on each side of a partition, and what does a read return right after a write in normal operation?
Remember
- During a partition you choose consistency (refuse requests) or availability (serve possibly stale data)
- P is not optional in a distributed system
- PACELC adds the everyday trade-off: latency vs consistency
Watch out for
- Describing a single-node database as 'CA' — CAP is about replicated systems under partition.