The most rigorous treatment of consistency models available. Chapter 9 (Consistency and Consensus) is essential reading once you have the basics. For now, focus on Chapter 5.
Every database choice is a consistency choice. When you pick MySQL over Cassandra, or when you add a read replica, you are making a trade-off between consistency, availability, and partition tolerance. Without understanding CAP, your database choices will be guesswork.
In a distributed system, you can guarantee at most two of these three properties:
Network partitions (nodes losing communication) are inevitable in distributed systems. So you always need P. The real choice is: when a partition happens, do you sacrifice C (return potentially stale data but stay available) or A (refuse to answer to avoid returning stale data)?
During a partition, a CP system refuses to answer rather than risk returning stale data. You get an error instead of a potentially wrong answer.
Use when: Data accuracy is critical. Financial transactions, inventory management, distributed locks, leader election.
Examples: ZooKeeper, HBase, Spanner, Redis (single-leader)
Your bank balance must be consistent. If the primary DB is partitioned from its replica, you'd rather get an error ("service temporarily unavailable") than see the wrong balance.
During a partition, an AP system keeps serving requests but may return stale data. The system "eventually" becomes consistent once the partition heals.
Use when: Availability matters more than perfect accuracy. Social media feeds, shopping cart, DNS, content delivery.
Examples: Cassandra, DynamoDB, CouchDB, most DNS systems
Your Twitter follower count being 1 second out of date is acceptable. The feed staying available during a datacenter partition is critical.
CAP is a binary framing. In practice, consistency exists on a spectrum:
| Model | Guarantee | Trade-off |
|---|---|---|
| Strong Consistency | Every read sees the most recent write | Higher latency, lower availability (must wait for all replicas) |
| Linearizability | Operations appear to happen at one point in time, in real-time order | Very expensive — used for consensus systems (Raft, Paxos) |
| Sequential Consistency | Operations from each client appear in the order they were issued, but clocks aren't synchronized across clients | Moderate cost |
| Eventual Consistency | Given no new writes, all replicas will converge to the same value eventually | High availability, low latency — most NoSQL DBs |
| Causal Consistency | Operations that are causally related are seen in order; concurrent ops may be seen differently | Good middle ground (MongoDB default) |
When you pick a database in an interview, always qualify your consistency requirement. "For the user profile service, I'll use PostgreSQL with strong consistency since we can't have users see stale profile data. For the activity feed, I'll use Cassandra with eventual consistency — slightly stale is fine and we need the write throughput."
Atomicity: all or nothing
Consistency: DB always in valid state
Isolation: concurrent txns don't interfere
Durability: committed = permanent on disk
Use: financial records, inventory,
anything where partial writes are catastrophicBasically Available: system stays up
Soft state: state can change over time
Eventually consistent: converges eventually
Use: social feeds, shopping carts,
anything where scale > strict accuracy