⚖️ CAP Theorem Explained

Abstract

🌐 📋 Brewer’s theorem: in the face of network partitions, a distributed data store can deliver at most two of consistency, availability, and partition tolerance.

Core Guarantees

Guarantee	Definition	Notes
Consistency	Every read returns the most recent write (or errors).	Differs from ACID consistency; refers to linearizable reads.
Availability	Every request receives a non-error response, regardless of staleness.	Clients always get a reply.
Partition Tolerance	System continues operating despite message loss or delays between nodes.	Realistic distributed systems must assume partitions.

Tip

🌐 🔥 Trade-offs arise only during partitions. Without a partition, you can deliver consistency and availability simultaneously.

Choosing During a Partition

Combination	What you keep	What you sacrifice	Typical Systems
CP	Consistency + Partition tolerance	Availability	Banking, stock trading, critical configuration stores
AP	Availability + Partition tolerance	Consistency	Social feeds, DNS, shopping carts
CA	Consistency + Availability	Partition tolerance	Only feasible in single-node or tightly coupled clusters

Note

🔵 ✏ CA systems cease to be CA once the network partitions—they must degrade into CP or AP behavior.

Example Walkthrough

• Consistency-first: three-node cluster requires acknowledgements from all nodes before serving reads. On partition, isolated nodes reject requests.
• Availability-first: nodes continue serving reads/writes locally even when disconnected, accepting stale data for uptime.
• Partition tolerance: regardless of strategy, the cluster keeps functioning in the presence of lost or delayed messages.

Consistency Modes

Level	Description	Use Cases	Example Technologies
Weak consistency	No guarantees on reads; best effort replication.	Realtime media streams, gaming.	VOIP, multiplayer servers.
Eventual consistency	Data converges over time; replicas sync asynchronously.	Social apps, DNS, email.	DynamoDB, Cassandra, DNS.
Strong consistency	Reads always reflect the latest writes; synchronous replication.	Financial systems, ledgers.	RDBMS, ZooKeeper, Spanner (with scoped latency).

Note

Consistency as defined in the CAP theorem is quite different from the consistency guaranteed in ACID database transactions.

Tip

Consistency in ACID

• Changing one consistent state to another consistent state

Consistency in CAP

• Getting the latest updated data or Error

Note

No distributed system is safe from network failures, thus network partitioning generally has to be tolerated.

Important

• CAP is frequently misunderstood as if one has to choose to abandon one of the three guarantees at all times. In fact, the choice is really between consistency and availability only when a network partition or failure happens; at all other times, no trade-off has to be made.

Real-World Example

Consider a system with three nodes (A, B, C):

Scenario 1: Consistency

• All nodes (A, B, C) maintain the same data
• When B updates data, it must propagate to A and C
• System ensures all nodes show same data or returns error

Scenario 2: Availability

• If node B fails, A and C continue operating
• System keeps responding to requests
• May not have most recent data

Scenario 3: Partition Tolerance

• Network partition separates B from A and C
• System continues functioning despite partition
• May sacrifice either consistency or availability