If you’re building or using distributed systems like databases or microservices, you’ve probably come across the term CAP Theorem. But what does it really mean, and why should you care?
CAP theorem, also known as Brewer’s Theorem, states that in any distributed data system, it is impossible to simultaneously provide all three of the following guarantees:
- Consistency (C)
- Availability (A)
- Partition Tolerance (P)
You can choose only two out of the three. A system can satisfy at most two at any given time, especially during a network partition.
The Three Guarantees Explained
1. Consistency
Every read receives the most recent write or an error. All nodes in the system return the same, up-to-date value when queried.
Example: If you write x = 5 and then immediately read x, you should get 5 on every node.
2. Availability
Every request (read or write) receives a response, even if it’s not the most recent value. The system remains operational and responsive.
Example: Even during server issues, a request returns a value—possibly outdated—but not an error.
3. Partition Tolerance
The system continues to function even if network communication fails between some nodes. It can handle message delays or drops between partitions.
Example: A region’s servers stay functional even if disconnected from another region.
CAP Trade-offs
During a network partition, you must choose between consistency and availability:
| Choice | Implication |
|---|---|
| CP System | Denies some requests to maintain consistent state. |
| AP System | Responds to all requests but may return stale data. |
| CA System | Only works when no partition exists (ideal but impractical). |
CAP Scenarios in Practice
1. CP (Consistency + Partition Tolerance)
Ensures consistent state across nodes even during network failures. May delay or reject requests.
Use cases: Banking systems, payment gateways
Examples: Google Spanner, HBase, Zookeeper
2. AP (Availability + Partition Tolerance)
Keeps the system responsive during partitions but may serve stale or inconsistent data.
Use cases: Shopping carts, product catalogs
Examples: DynamoDB, Cassandra, Couchbase
3. CA (Consistency + Availability)
Maintains consistent and available operations—but only when network is fully intact (no partition).
Use cases: Centralized databases, testing environments
Examples: Traditional MySQL/PostgreSQL on a single node
Conceptual View
Consistency
/ \
/ \
/ \
Availability — Partition Tolerance
During a partition, you can pick only one side: CP or AP.
Summary Table
| System Type | Guarantees | Sacrifices | Use Case | Example Technologies |
|---|---|---|---|---|
| CP | Consistency + Partition Tolerance | Availability | Banking, payments | Google Spanner, Zookeeper |
| AP | Availability + Partition Tolerance | Consistency | Shopping carts, social apps | DynamoDB, Cassandra, CouchDB |
| CA | Consistency + Availability | Partition Tolerance | Centralized SQL systems | MySQL, PostgreSQL (non-distributed) |
Important Notes
- Partition Tolerance is essential in any real-world distributed system.
- CAP theorem applies primarily during network partitions.
- System design should be based on which two guarantees matter most for your use case.