The CAP theorem is the classic rule for reasoning about distributed databases. It says that during a network partition, a distributed system can guarantee at most two of three properties. Understanding it helps you justify database choices.
The three properties
- Consistency (C) — every read sees the most recent write (all nodes agree).
- Availability (A) — every request gets a (non-error) response, even if some nodes are down.
- Partition tolerance (P) — the system keeps working when the network between nodes drops messages.
Why you must choose during a partition
In any real distributed system, network partitions will happen, so P is not optional. When a partition occurs you must choose:
- CP — stay consistent by rejecting requests that can't be confirmed (sacrifice availability). Example: many SQL/consensus systems.
- AP — stay available by answering with possibly stale data (sacrifice strong consistency). Example: Cassandra, DynamoDB with eventual consistency.
Eventual consistency
AP systems are usually eventually consistent — after writes stop, all replicas converge to the same value given enough time. That's perfectly fine for things like social feeds or like-counts, but not for a bank balance.
PACELC — the fuller picture
CAP only talks about behaviour during a partition. PACELC extends it: if there is a Partition, choose between Availability and Consistency; Else (normal operation) choose between Latency and Consistency. It captures the everyday trade-off that even without partitions, stronger consistency costs latency.