Consistency, Availability, and Network Partitions
Published on
CAP describes a distributed system’s behavior when communication is partitioned. During a partition, a replicated operation cannot guarantee both linearizable consistency and that every request receives a non-error response. Outside a partition, systems still make latency and consistency tradeoffs, often summarized by PACELC.
Terms
- Consistency in CAP: operations appear to execute atomically in a single global order, commonly discussed as linearizability.
- Availability in CAP: every request to a non-failing node eventually receives a non-error response, even if the response cannot include the latest write.
- Partition tolerance: the system continues operating despite lost or delayed messages between groups of nodes.
Real distributed systems must expect partitions, so design focuses on which operations preserve consistency, which remain available, and how conflicting or delayed state is repaired. The choice can differ by operation: account balance updates may reject work while a product catalog serves stale data.
Questions for a design
- Which invariants must never be violated?
- Can an operation wait, fail, or return stale data during loss of coordination?
- How are conflicts detected and resolved?
- What consistency does a client observe across retries, sessions, and regions?
- How does the system recover after partitions heal?
Avoid classifying an entire database permanently as “CP” or “AP.” Configuration, topology, operation type, consistency level, and failure state determine behavior. Also avoid equating SQL with consistency or NoSQL with availability; products in both groups support different transaction, replication, and scaling models.