CAP says you can have at most two of: Consistency, Availability, Partition tolerance. Real systems must tolerate partitions, so the tradeoff is between consistency and availability. Understanding consistency models lets you make this choice explicitly.
CAP Theorem
In a distributed system, partitions (network splits between nodes) are guaranteed to happen. When they do:
- CP (Consistency + Partition): If nodes can't communicate, reject writes. Guarantees consistency but loses availability.
- AP (Availability + Partition): Keep accepting writes even if nodes are split. Guarantees availability but sacrifice consistency.
You cannot pick CA. No partition tolerance means no network between nodes, which is impossible in practice.
Example: Two-Node Database Across Network Partition
Node A --- Network Partition --- Node B
Client writes to A: UPDATE user SET name="Alice" (succeeds)
Client reads from B: SELECT name ... (gets old name "Bob")
A and B are inconsistent.
Options:
1. Keep both nodes available (AP): A and B serve different answers.
2. Reject B's reads (CP): wait for partition to heal, then sync.
Consistency Models (Ordered by Strength)
1. Linearizability (Strict Consistency)
Definition: Reads always see the most recent write.
How it works:
- Write occurs at time T.
- Any read after T sees the write.
- No stale reads.
Cost: Requires coordination (quorum writes, consensus). High latency.
When: Financial transactions, inventory (must not oversell).
2. Sequential Consistency
Definition: Operations happen in some total order, visible to all clients.
How it works:
- Writes are serialized globally.
- All clients see the same order.
Cost: Expensive coordination.
Reality: Rarely guaranteed; hard to achieve at scale.
3. Causal Consistency
Definition: If write A causally affects write B, all reads see A before B.
How it works:
- Use logical timestamps (Lamport clocks, version vectors).
- If you read X, then write Y, all future readers see X before Y.
Cost: Moderate (track causality).
Example: Social media (comments must see the post they reply to).
4. Read-Your-Writes Consistency
Definition: After you write, your reads see the write (but others might not yet).
How it works:
- Sticky sessions: your requests hit the same server.
- Or: read from leader after write.
Cost: Low (sticky sessions).
Example: User updates profile, wants to see updated profile immediately.
5. Eventual Consistency
Definition: Reads eventually see all writes, but not immediately.
How it works:
- Writes asynchronously replicate.
- After delay, all nodes converge to the same state.
Cost: Very low (no coordination). Trade-off: Temporarily inconsistent reads.
Example: Caches, social feeds, user followers count.
Quorum Writes and Reads
A way to tune consistency without rigid CP/AP:
Quorum: Require acknowledgment from a majority.
Replicate count: 3 (nodes A, B, C)
Write quorum: 2 (write to A and B, continue even if C is down)
Read quorum: 2 (read from 2 nodes, at least one has the latest write)
Write quorum + Read quorum > Total replicas ensures reads see latest write.
2 + 2 > 3? No. Risky.
Write quorum: 3 (write to all 3, or fail)
Read quorum: 1 (read from any, guaranteed to be latest because all writes went to all nodes)
3 + 1 > 3? Yes. Safe but slow writes.
Write quorum: 2, Read quorum: 2, Replicas: 3
2 + 2 > 3? Yes. Safe. If one node fails, writes and reads still work.
Dynamo/Cassandra tune this: W (write quorum) + R (read quorum) parameters let you balance consistency and latency per operation.
Consistency vs Latency Trade-offs
| Model | Latency | Consistency | Example | |-------|---------|-------------|---------| | Linearizable | High (quorum writes) | Strong | Banking | | Causal | Moderate | Medium | Messaging (causal order) | | Read-your-writes | Low (sticky sessions) | Weak | User profiles | | Eventual | Very low (async) | Weak (lag seconds) | Caches, feeds |
Practical Approach
Start eventual: Fastest, simplest. Most data is fine with this.
Add consistency where needed:
- Financial transactions → Linearizable (one database or consensus).
- User data → Read-your-writes (sticky sessions or read from leader).
- Feeds, caches → Eventual (replicate asynchronously).
In the interview
-
Know CAP: "Systems pick AP or CP. I'd choose AP (availability, eventual consistency) for a feed, CP (consistency) for financial data."
-
Discuss consistency models: "I'd use read-your-writes for user data (sticky sessions) and eventual consistency for cache."
-
Mention quorums: "I'd require writes to hit 2/3 replicas and reads from 2/3, ensuring safety if one replica is down."
-
Tradeoff discussion: "Linearizability is safe but slow. Eventual consistency is fast but temporarily inconsistent. I'd use eventual for high-volume, low-criticality data."