CAP, stated correctly
In a distributed data store, when a network Partition happens, you must choose between:
- Consistency: every read sees the latest write, or you get an error.
- Availability: every request gets a non-error response, possibly stale.
Partitions are not optional in real networks. So it's not "pick 2 of 3". It's "when a partition happens, pick C or A."
PACELC — the everyday trade-off
| System (typical config) | PACELC | Notes |
|---|---|---|
| DynamoDB, Cassandra | PA/EL | Tunable; defaults favour availability and latency |
| MongoDB (majority writes and reads) | PC/EC | Tunable via write/read concern |
| Spanner, CockroachDB | PC/EC | Consistency first, with engineering to minimise latency |
| Redis (async replicas) | PA/EL | Failover can lose acknowledged writes |
How to use this in design
Decide per operation, not per system:
- Inventory decrement, payments, permission changes: CP.
- Product views, feeds, analytics counters: AP is fine.
- Content preview can be strongly consistent while CDN delivery is eventually consistent. Same product, different choices.
Cheatsheet
The whole topic on one page. Click to open full screen.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Consistency Models
From linearizable to eventual — what each guarantee means for users, and practical models like read-your-writes and monotonic reads.
Replication
Keep copies of data on multiple nodes for availability, durability and read scaling — single-leader, multi-leader and leaderless, sync vs async.
MongoDB at Enterprise Scale
Data modelling by access pattern, indexing (ESR rule), transactions, change streams and the operational gotchas of large multi-tenant collections.