TechBlueprints Quick Reference
Every read returns the most recent write
All nodes see the same data at the same time
Every request gets a response
System never refuses requests (may return stale data)
System works despite network failures
Required in distributed systems - not optional!
In a distributed system, network partitions WILL happen. So you must choose:
Refuse requests during partition to maintain consistency
→ Some requests fail, but data is always correct
Always respond, even if data might be stale
→ All requests succeed, but data may be inconsistent
| Database | Type | Behavior During Partition |
|---|---|---|
| PostgreSQL | CP | Primary blocks writes until partition heals |
| MongoDB | CP | Minority partition becomes read-only |
| Redis Cluster | CP | Requires majority of masters available |
| Cassandra | AP | All nodes accept writes, resolve conflicts later |
| DynamoDB | AP | Eventually consistent by default |
| CouchDB | AP | Multi-master with conflict resolution |
"CAP theorem states that in a distributed system, when a network partition occurs, you must choose between consistency and availability. There's no avoiding this trade-off."
"For [this system], I'd choose [CP/AP] because [specific reason]. If we chose [other option], we'd risk [specific consequence]."
CAP is not "pick 2 of 3". It's really: "When partition happens (it will), pick C or A". When there's no partition, you can have both C and A!