Exercises — BASE vs ACID

This is Durability (the D in ACID). "Committed data survives crashes because it is written to permanent storage." The tell-tale phrase is survives even if power dies — that is about persistence after commit, not about correctness or ordering.

It is Basically Available — the system always answers fast rather than failing or blocking. It is not Eventual consistency by itself. Eventual consistency is the promise that the replicas will later agree; "answering instantly with a possibly-old value" is the availability part. They travel together but name different things: one is "you always get a reply", the other is "the replies converge over time."

(a) = CP (Consistency + Partition-tolerance; it sacrifices Availability by refusing). (b) = AP (Availability + Partition-tolerance; it sacrifices strong Consistency, going eventual). Remember: P is mandatory because networks will partition, so the only real choice is C vs A.

Selling the same seat twice is expensive: refunds, angry customers, legal cost. So cost-of-wrong is large. A booking page being slow for a moment is annoying but cheap: cost-of-down is small. Since cost-of-wrong is far bigger than cost-of-down, the rule says pick ACID / CP. You would rather block or refuse a booking than risk a double-sold seat.

A wrong "typing…" bubble costs essentially nothing, so cost-of-wrong is tiny. Lag would make the app feel broken, so cost-of-down dominates. Since cost-of-down is far bigger than cost-of-wrong, pick BASE / AP. Answer instantly from the local replica; let it be a little stale.

ACID with Isolation: the two withdrawals are forced into some serial order. First sees $150, takes $100 → $50 left. Second sees $50, its $100 withdrawal is rejected (would break the balance ≥ 0 rule = ACID's C). Final balance = $50, exactly one withdrawal succeeds. Total money removed = $100. Loose BASE (no coordination): both replicas read $150, both approve $100. When they sync, the account can end at $-50 (overdrawn) or lose one write depending on the merge — money invariant broken. This is why money uses ACID.

First, the term you'll need: soft state means the stored data can differ across replicas, and can change on its own while background sync runs, even when nobody sends new input. It is the "temporarily out-of-step" middle stage between a write and full agreement. Now the scenario: within that 200 ms window the second replica hasn't received the write yet, so the user may read their own write as the OLD value — the "read-your-writes" surprise. This demonstrates soft state (the two replicas hold different values mid-sync, with no new input) followed by eventual consistency (after ~200 ms all replicas converge). Nothing is permanently wrong; only the timing is relaxed.

The AP line (solid red, labelled "AP" and sitting near the top) stays at ~100% availability through the partition — every request still gets an answer, but during the grey shaded partition window some answers are stale (correctness dips even though the line stays up). The CP line (black stepped line, labelled "CP") drops availability to 0% during the partition — it refuses requests on the minority side to guarantee no one ever reads wrong data. The trade is visible exactly in the grey band (which marks when the network is split): AP keeps the "we answered you" line high by letting correctness dip; CP keeps correctness perfect by letting the "we answered you" line fall to zero. After the partition heals, both return to normal and the AP replicas re-converge.

False. The definition has a condition: "if no new writes occur, all replicas eventually converge to the same value." The word "eventual" bounds when, not whether. Convergence is guaranteed given a quiet period; you only give up knowing exactly when the agreement lands, never the destination. The right mental picture: replicas are always walking toward the same point — remove new writes and they arrive.

• (a) Payment charge → ACID. Charging twice or losing a charge is money-wrong; cost-of-wrong huge. Needs Atomicity + Durability. (See ACID Transactions.)
• (b) Inventory decrement → ACID. Overselling a physical item = real cost; needs Isolation so two buyers can't grab the last unit.
• (c) View counter → BASE. Off by a few for a second harms nobody; needs high availability at scale.
• (d) Recommendations → BASE. Stale suggestions are fine; must never block the page. Key insight: the same app mixes contracts. Match the guarantee to each piece's cost of being wrong, not to the app as a whole.

The protocol is Two-Phase Commit (2PC; see Two-Phase Commit). Phase 1: a coordinator asks every participant "can you commit?" Phase 2: if all say yes, it tells everyone commit; if any says no, everyone aborts — giving cross-machine Atomicity. Weakness: it is blocking. If the coordinator crashes after participants voted "yes," they must wait holding locks — availability suffers. This is exactly the CP cost: to keep consistency across machines, you sacrifice availability during failures.

Let p = 0.99 be one replica's availability, so its failure probability is (1 − p) = 0.01. AP (need at least 1 up). Walk the logic: the only way AP fails to answer is if every replica is down at once. For independent replicas, "all three down" is (1 − p) × (1 − p) × (1 − p) = (1 − p) cubed. So the chance it can answer is one minus that: A_AP = 1 − (1 − p)^3 = 1 − (0.01)^3 = 1 − 0.000001 = 0.999999. That's 99.9999% ("six nines") — availability went up by spreading across replicas, because you only need one survivor. CP (need all 3 up to agree). Here every node must be reachable for the system to answer, and "all three up" is p × p × p = p cubed: A_CP = p^3 = (0.99)^3 = 0.970299. That's ≈ 97.03% — availability went down, because the weakest link drags the whole chain. Lesson: the same replicas give 99.9999% vs 97.03%. AP treats replicas as redundancy (any one answers → multiply the failures); CP treats them as a chain (all must agree → multiply the successes). This is the CAP trade in raw numbers.

With n = 1: the AP formula 1 − (1 − p)^1 = p = 0.99, and the CP formula p^1 = 0.99. They coincide — both give 99%. Why: with one node there is no network between replicas to partition, so the P in CAP never triggers, and the C-vs-A choice vanishes. CAP is a statement about distributed systems; at n = 1 it degenerates to "the machine is either up or down." This is the boundary case where the whole ACID-vs-BASE distributed tension disappears — a single node can be strict and fast cheaply, exactly as the parent's core intuition said.

Lag → 0 (walk the reasoning). Eventual consistency's whole "staleness" comes from the gap in time between a write landing on one replica and reaching the others. Shrink that gap toward zero and there is no window in which replicas can disagree: the instant you write, every replica already has it, so any read anywhere returns the latest value. "Every read sees the latest write" is exactly the definition of strong consistency. So strong consistency is just eventual consistency with the lag squeezed out — the zero-lag limit. Lag → ∞ (walk the reasoning). Now writes never reach other replicas. The precondition of the eventual-consistency promise — "sync eventually completes" — is broken, so replicas can disagree forever. That is a partition that never heals: permanent divergence, i.e. no consistency at all. Insight: eventual consistency lives on a spectrum controlled by lag. Small lag ≈ strong consistency; unbounded lag ≈ no consistency. Real systems keep lag small and bounded so the "eventual" is measured in milliseconds, which is why the like-count example felt harmless.

• L1: name the guarantee — Durability, Basically-Available, CP/AP.
• L2: decide by cost-of-wrong vs cost-of-down — seats→ACID, typing→BASE.
• L3: replication lag causes stale reads (soft state), then convergence.
• L4: mix contracts per data-piece; 2PC extends atomicity but blocks.
• L5: AP availability = 1 − (1 − p)^n (fails only if all n down); CP = p^n (needs all n up); at n = 1 they meet; lag → 0 gives strong consistency.