CAP, stated correctly
A distributed store can't simultaneously guarantee all three of Consistency, Availability, Partition-tolerance. Since network partitions will happen, P isn't optional — so the real choice during a partition is:
- CP — refuse some requests to stay consistent (e.g. a banking ledger).
- AP — keep serving, accept that replicas may diverge and reconcile later (e.g. a social feed, a shopping cart).
Here's the moment CAP actually bites — the same partition, the two choices:
When the network is healthy you can have both consistency and availability. CAP only bites during a partition. PACELC extends it: Else (no partition), you still trade Latency vs Consistency — strong consistency costs round trips.
The consistency spectrum
| Model | Guarantee | Example |
|---|---|---|
| Strong | every read sees the latest write | balances, inventory decrement |
| Read-your-writes | you see your own updates immediately | edit your profile |
| Monotonic reads | you never see time go backwards | a paginated feed |
| Eventual | replicas converge "soon" | view counts, social timelines |
Most large systems are eventually consistent by default and reserve strong consistency for the few operations that truly need it.
Replication lag is where this spectrum stops being abstract. A write lands on the leader and the followers fall behind; read from a follower that hasn't caught up and you've broken read-your-writes. Sync the follower and the read goes fresh — watch the lag open and close:
1/8Writes go to the leader; followers apply the leader's log asynchronously and serve reads. Equal versions = caught up.
ACID vs BASE
- ACID (classic RDBMS): Atomicity, Consistency, Isolation, Durability — transactions are all-or-nothing and isolated. Great for money, orders, anything with invariants. StockStump's balance decrement needs this.
- BASE (many NoSQL): Basically Available, Soft state, Eventually consistent — trades strict guarantees for availability and scale.
The decision isn't ideological — it's per-workload. A trading balance is ACID; a "who viewed your profile" counter is happily BASE.
Design drills
CAP is a decision tool, not trivia. Practise choosing per workload.
Whiteboard each one out loud for 5–10 minutes before you reveal what a strong answer covers — the gap between your sketch and the checklist is your study list. Progress is saved on this device.
A network partition splits your replicas. For (a) a bank ledger and (b) a 'who's viewing this' counter, do you choose CP or AP — and what does the user experience?
A user updates their profile, then immediately reloads and sees the OLD value. Diagnose and fix without making the whole system strongly consistent.
Which of these need strong consistency and which are happily eventual: seat booking, like counts, account balance, a paginated feed?
Two users decrement the last unit of inventory at the same time on an AP store. What happens, and how do you make it safe?