CAP and Consistency Models

CAP and Consistency Models — Tech Epitome

What CAP actually says

CAP is usually recited as 'pick two of consistency, availability, partition tolerance', which makes it sound like a menu. It is not one — network partitions are a fact about networks, not a design option. You do not choose whether they happen.

Concept

The precise version

When a network partition occurs, a system must choose: refuse to answer until it can be sure the answer is current (giving up availability), or answer from what it has locally (giving up consistency). That is the whole theorem.

The theorem therefore describes behaviour during a partition — a rare event — and says nothing about the rest of the time. Most of the design work is in the rest of the time, which is why CAP is a starting point rather than a framework.

The spectrum between the endpoints

Model	Guarantees	Costs
Strong / linearizable	Every read sees the latest write	Coordination on every operation
Read your writes	You see your own changes	Routing or session pinning
Monotonic reads	You never see time go backwards	Sticky replica selection
Causal	Related events observed in order	Tracking causality
Eventual	Copies converge, eventually	Readers may see stale or conflicting data

CAP names the top and bottom rows. The middle is where products actually live.

Coordination is expensive

Agreement between machines requires round trips, and a majority must participate. That puts a floor under latency that no amount of optimisation removes, and it means availability now depends on a majority being reachable.

This is why the practical advice is avoid needing coordination rather than 'make coordination fast'. Partition data so that operations touch one partition. Model operations so that order does not matter. Make writes idempotent so a retry is harmless. Each of these removes a coordination requirement instead of paying for it.