Distributed systems become difficult when data is split across machines that can fail independently and communicate over networks. CAP is a useful way to reason about one specific tradeoff: what guarantees a system can provide when a network partition prevents nodes from communicating reliably.
The three terms
- Consistency: reads behave according to a defined ordering of writes.
- Availability: a non-failing node returns a response to a request.
- Partition tolerance: the system continues operating despite a communication partition.
The important nuance
CAP is not a menu where an engineer simply picks two letters during normal operation. When a partition occurs, a distributed system must choose whether to reject or delay some operations in order to preserve stronger consistency, or continue serving operations with weaker consistency guarantees.
A simple example
Imagine two replicas of an account service. A network partition means replica A cannot reach replica B. A client asks A to withdraw money while another client updates B. If the system continues accepting both operations independently, it may temporarily allow states that cannot be presented as one globally ordered history.
Consistency is a spectrum
Real systems often expose more than “strong” or “eventual” consistency. Linearizability gives operations a behavior close to a single global timeline. Eventual consistency allows replicas to converge after updates propagate. Session-level guarantees can provide useful properties for a single user without imposing the cost of global ordering everywhere.
Availability has context too
Saying a system is “available” is incomplete without defining the failure model, timeout behavior, and which operations are allowed. A system can return quickly but still provide stale or rejected results depending on its contract.
Design questions to ask
- What must never happen, even during a failure?
- Can temporary stale reads be tolerated?
- Which operations can safely be retried?
- How are conflicting writes detected or merged?
- What happens when a replica or region becomes unreachable?
How this connects to system design
CAP becomes useful when you connect it to replication, quorum reads and writes, failover, leader election, and client retry behavior. Ourdistributed systems deep diveexplores those mechanisms from an architecture perspective.
Key takeaway
CAP is best used as a failure-mode reasoning tool. It does not say that one database is universally better than another; it asks what behavior your product can accept when the network itself stops cooperating.