CAP theorem is a fundamental principle in distributed systems that explains the inevitable trade-offs between consistency, availability, and partition tolerance. It helps system designers understand why certain guarantees cannot all be achieved at the same time when data is distributed across multiple machines.
Although often misunderstood or oversimplified, CAP theorem provides a useful mental model for making informed architectural decisions.
CAP theorem states that a distributed system can only fully guarantee two out of the following three properties at any one time:
Consistency
Availability
Partition tolerance
The theorem becomes relevant when a network partition occurs — meaning communication between parts of the system is disrupted. In that situation, the system must choose between being consistent or being available.
Rather than being a design goal, CAP describes a constraint imposed by the realities of distributed computing.
Consistency means that all clients see the same data at the same time.
After a successful write, every subsequent read — no matter which node it is served from — returns the most recent value or an error. This is similar to strong consistency in databases, where there is a single, up-to-date view of the data.
Consistency does not refer to data correctness rules (as in ACID), but to the uniformity of data across replicas.
Availability means that every request receives a response, even if that response does not contain the most recent data.
The system continues to operate and respond, rather than failing or timing out, as long as the node handling the request is reachable.
An available system prioritises uptime and responsiveness, sometimes at the cost of returning stale data.
Partition tolerance means the system continues to function despite network failures that prevent some nodes from communicating with others.
In distributed systems, network partitions are unavoidable — caused by hardware failures, network congestion, or data centre outages. Any system spanning multiple machines must assume partitions will happen.
As a result, partition tolerance is typically non-negotiable.
The key insight of CAP theorem is that during a partition, a system must choose between consistency and availability.
CP systems (Consistency + Partition tolerance)
These systems prioritise correctness. When a partition occurs, they may reject requests or become temporarily unavailable to ensure data remains consistent.
Examples: traditional relational databases with strong consistency guarantees.
AP systems (Availability + Partition tolerance)
These systems prioritise responsiveness. They continue to serve requests during a partition, even if some responses are based on stale data.
Examples: many NoSQL databases and distributed caches.
CA systems (Consistency + Availability)
These systems work only when there are no partitions. In practice, they are limited to single-node or tightly coupled systems and are not truly distributed.
In reality, modern systems often sit along a spectrum, dynamically adjusting behaviour depending on the operation and the current conditions.
CAP theorem explains why distributed systems must make hard choices.
When network partitions occur — and they will — a system must choose whether to prioritise consistency or availability. Understanding this trade-off helps engineers design systems that align with real-world requirements rather than unrealistic expectations.