Consistency, Availability, Partition Tolerance — pick two. Fundamental law of distributed systems.
The Three Pillars
🔒
Consistency
Every read receives the most recent write or an error. All nodes see the same data at the same time — no stale reads.
LinearizableStrongACID
Use case:Financial transactions, inventory counts, user auth — where stale data causes real harm
🟢
Availability
Every request receives a non-error response, without guarantee that it contains the most recent write. The system is always operational.
Always OnNo DowntimeResponsive
Use case:Social media feeds, content delivery, shopping carts — where uptime beats precision
🌐
Partition Tolerance
The system continues to operate despite arbitrary message loss or failure of part of the system. Network splits don't bring it down.
Network SplitsDistributedFault Tolerant
Use case:Any multi-node distributed database operating across multiple data centers or cloud regions
Decision Flow
How the CAP trade-off plays out when a partition occurs
flowchart TD
Client([👤 Client Request])
Client --> Decision{Network Partition?}
Decision -->|No Partition| CA[✅ Full C + A<br/>RDBMS / Single Node]
Decision -->|Partition Occurs!| Choice{Choose One}
Choice -->|Keep Consistency| CP[🔒 CP System<br/>Refuse stale requests]
Choice -->|Keep Availability| AP[🟢 AP System<br/>Serve possibly stale data]
CP --> CPResult[❌ Some requests fail<br/>✅ Data always correct]
AP --> APResult[✅ All requests succeed<br/>⚠️ Data may diverge]
CA --> CAResult[⚠️ Cannot handle partitions<br/>✅ Best for single-node]
style Client fill:#1a1f2b,stroke:#ffab00,color:#fff
style Decision fill:#1a1f2b,stroke:#ffab00,color:#fff
style Choice fill:#1a1f2b,stroke:#ff6e40,color:#fff
style CA fill:#1a2e1a,stroke:#3effa3,color:#fff
style CP fill:#1a2030,stroke:#00e5ff,color:#fff
style AP fill:#2a1f1a,stroke:#ffab00,color:#fff
style CPResult fill:#0d1117,stroke:#00e5ff,color:#aaa
style APResult fill:#0d1117,stroke:#ffab00,color:#aaa
style CAResult fill:#0d1117,stroke:#3effa3,color:#aaa
Interactive CAP Triangle
Explore how systems choose between C, A, and P
Waiting...
CP: Consistency + Partition Tolerance
🔒C
Consistency
🟢A
Availability
🌐P
Partition Tol.
1
A network partition occurs — nodes can't communicate
2
The system detects the partition event
3
System refuses writes to minority partition — ensures all reads return the latest data
4
Some client requests get errors (503) — unavailable until partition heals
5
✓ Strong consistency guaranteed — no stale reads. Cost: downtime during partitions.
Chosen
Sacrificed
Active
Key Concepts
Essential insights for understanding CAP in practice
Network Partitions are Inevitable
In distributed systems, network failures WILL happen. You cannot "choose" to skip partition tolerance — it's a reality. The real choice is between C and A during a partition.
Tip: Assume partitions will occur; focus on your C vs A trade-off strategy
Eventual Consistency
AP systems often use eventual consistency: given enough time without new updates, all nodes will converge to the same value. It's not "no consistency" — just delayed.
Example: DNS propagation, DynamoDB, Cassandra default mode
PACELC Extension
CAP only describes behavior during partitions. PACELC adds: "Else, choose Latency or Consistency." Even without partitions, there's a latency-consistency trade-off.
PACELC: if Partition → A or C; Else → Latency or Consistency
Real-World Examples
Popular databases and their CAP classifications
🍃MongoDBCP
Strongly consistent primary reads. During partition, minority side becomes read-only.
🏗️HBaseCP
Built on HDFS. Strong consistency via single RegionServer per region. Unavailable during region splits.
⚡Redis ClusterCP
Hash-slot based sharding. During partition, minority nodes stop accepting writes.
💎CassandraAP
Tunable consistency. Default: eventual. Always writable, even during partitions.
🟠DynamoDBAP
Eventually consistent reads by default. Designed for extreme availability.
🛋️CouchDBAP
Multi-master replication. Continues working offline, syncs and resolves conflicts later.
🐘PostgreSQLCA
Single-node: perfectly consistent + available. Not partition-tolerant by default.
🐬MySQLCA
Traditional single-server RDBMS. Full ACID. Partitions require external tooling.
📁SQLiteCA
Embedded single-file database. No network = no partition concern. Perfect CA.