Your friend refreshes your Instagram profile one second after you changed your profile picture. Should they see the new picture immediately, everywhere, no exceptions — or is a short delay acceptable? The honest answer is "it depends on the product" — and that one sentence is most of this lesson.
Strong vs eventual consistency
Strong consistency means every read, from any replica, immediately reflects the most recent write — no stale answers, ever. Eventual consistency means replicas are allowed to briefly disagree after a write, converging to the same value given enough time (usually milliseconds to a couple of seconds). A bank transfer needs strong consistency — showing the wrong balance for even a moment is a real problem. A social media like count can be eventually consistent — being off by one for a second harms nobody, and the trade buys real speed and availability.
Read-after-write consistency
A specific, very common bug: a user posts a comment, immediately refreshes, and their OWN comment is missing — though it shows up for everyone else moments later. This happens when the write lands on the leader/primary, but that user's very next read gets routed to a follower replica that hasn't caught up yet. Fixes include routing a user's own reads to the leader briefly after they write, or a session-level guarantee specifically promising "you will always see your own writes," even while other users might briefly see a slightly older version.
The CAP theorem, correctly stated
CAP is very commonly misquoted as "pick any two of Consistency, Availability, Partition tolerance, forever." That is not right. Partition tolerance is not optional in a real distributed system — networks genuinely fail sometimes, and a system has to survive that reality. The real choice only appears during an actual network partition: do the disconnected nodes keep answering requests with possibly-stale data (Availability), or refuse to answer until they can be sure they agree (Consistency)? Outside of a partition, a well-designed system can absolutely have both.
CP vs AP systems
A CP system chooses correctness over uptime during a partition — it would rather return an error or time out than serve data it can't guarantee is current (a bank's core ledger typically behaves this way). An AP system makes the opposite choice — stay up and serve SOMETHING, reconcile differences later (a shopping cart, or a social feed, typically behaves this way). Neither choice is universally correct — the right one depends entirely on what breaks worse for the SPECIFIC feature: showing something slightly wrong, or refusing to answer at all.
Quorum reads and writes
Some systems tune consistency with simple numbers instead of an all-or-nothing choice. With N replicas, a write quorum W and a read quorum R, if W + R > N, then by the pigeonhole principle, any write set and any read set must share at least one replica in common — guaranteeing a read is always able to see the most recent write. This lets a system dial consistency strength up or down by adjusting W and R, trading it directly against latency (a bigger quorum means waiting for more replicas to respond).
Common mistakes
- Reciting "pick any two of CAP" as a permanent, always-true rule instead of a during-a-partition choice.
- Applying the same consistency requirement to an entire system instead of deciding per-feature.
- Not naming what specifically is gained (availability/latency) and given up (staleness) when defending an eventual-consistency choice.
- Forgetting that read-after-write problems can look like "the write silently failed" bugs if not explained clearly.
Quick recap
| Concept | One-liner |
|---|---|
| Strong consistency | Every read reflects the latest write, always. |
| Eventual consistency | Replicas briefly disagree, then converge. |
| CAP theorem | The real choice (C vs A) only appears DURING a partition. |
| CP vs AP | Correctness-over-uptime vs uptime-over-perfect-correctness, chosen per feature. |
| Quorums | W+R > N guarantees a read sees the latest write. |
Practice Zone
Five MCQs, then two applied questions.
During a network partition between two data centers, what does the CAP theorem actually force you to choose between?
Asked in
Which of these products would most likely accept eventual consistency (a small delay before all replicas agree) as a reasonable trade-off?
Asked in
A user posts a comment and immediately refreshes the page, but their own comment is missing (though it shows up for other users a few seconds later). What consistency problem is this?
Asked in
A distributed database is described as 'CP' (consistent and partition-tolerant, sacrificing availability). What does that mean in practice during a network split?
Asked in
In a system with 5 replicas, using a write quorum W=3 and read quorum R=3, why does W+R > N (3+3 > 5) guarantee strong-ish consistency?
Asked in
A ride-hailing app has two features: (1) showing a driver's live location on the map, and (2) confirming that a ride was booked and charged to the rider. For each, argue whether it should behave like a CP system or an AP system during a network hiccup, and why.
Asked in
A support ticket says: 'I updated my profile picture on my phone, but my laptop still shows the old one, even after refreshing several times over the next minute.' What are two plausible, different-layer causes, and how would you distinguish them?
Asked in
FAQ
Is CAP the same as ACID?
No — ACID describes guarantees within a single database transaction (atomicity, consistency, isolation, durability). CAP describes trade-offs ACROSS a distributed system during a network partition. They address different problems.
Can a system be both CP and AP, in different parts?
Yes, and this is common — a single application often makes different CP/AP choices for different features, exactly as the ride-hailing location-vs-payment example in this lesson's exercises shows.
Is eventual consistency always 'bad'?
Not at all — for the right feature, it's a deliberate, sensible trade for much better availability and latency, not a corner cut. The mistake is applying it somewhere that genuinely needed strong consistency.