Loading content
The CAP theorem, formulated by Eric Brewer, states that in a distributed data system, it is impossible to guarantee all three properties – consistency, availability, and partition tolerance – simultaneously. In the event of a network partition, a system must choose between consistency or availability. This has far-reaching implications for the design and imp…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
The CAP theorem describes a limit of distributed data systems: once a network is partitioned, a system cannot fully guarantee both consistency and availability; partition tolerance is the condition that makes this trade-off visible.
Eric Brewer formulated the CAP theorem in the late 1990s from the observation that distributed data stores cannot promise maximum consistency and availability at the same time during network failures. The idea appeared in 1998, was published as the “CAP principle” in 1999, presented at PODC in 2000, and formally proved by Gilbert and Lynch in 2002. Later debate clarified the terms, but not the underlying conflict.
Think of a distributed system as a triangle. Under normal operation, fresh data, answers to every request, and continued operation across node groups can coexist. When the network between nodes breaks, the partition forces a per-request decision: wait for the latest confirmed state, or keep serving the reachable side.
Multiple nodes coordinate over a network; that distribution is what makes the conflict relevant.
Readers see the same current state or receive an error.
Every request to a reachable node receives a response.
The system remains operational despite lost or delayed messages between nodes.
Communication splits into separate subnets; not every node can reach every other node.
The CAP theorem helps when designing replication, failover, and the balance between strict data consistency and continued service under failure. It matters most for distributed databases, global services, and unstable networks. It is not a product decision rule: CAP consistency is not the same as ACID consistency, and outside a partition all three properties can coexist.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.