CAP Theorem — Consistency, Availability, Partition Tolerance

Takeaway

Under network partitions, a system must choose between immediate consistency and availability; designs position along this trade-off with specific guarantees.

The problem (before → after)

Before: Wish for perfect consistency and uptime, even with partitions.
After: Clarify guarantees under partitions and choose mechanisms accordingly.

Mental model first

If the bridge between two towns collapses, each town can keep operating independently (availability) or halt decisions until reconnection to stay perfectly consistent.

Just-in-time concepts

Consistency (linearizability) vs eventual vs causal.
Partition tolerance: continue despite message loss/delay.
PACELC: Else, trade latency vs consistency without partitions.

First-pass solution

Define target consistency; use replication and coordination (quorums, consensus) or avoid coordination with CRDTs and idempotent semantics.

Tunable quorums (R/W/N) trade read vs write guarantees.
Multi-region and WAN considerations.
Observability for debugging consistency issues.

Principles, not prescriptions

Make trade-offs explicit and test failure modes.
Provide clear client guarantees.

Common pitfalls

Misstating CAP as choosing only two always; it’s about partitions.
Hidden assumptions about failure detectors and time.

Connections and contrasts

See also: [/blog/crdts], [/blog/raft-consensus], [/blog/consensus-paxos].

Quick checks

When is CAP relevant? — During partitions.
What is PACELC? — Else, latency–consistency tradeoff.
Can we get all three? — Only without partitions; in reality, plan for them.