BASE vs ACID: Question bank — Coding deep dive

Before you start, a quick vocabulary anchor so no word is used unexplained:

A replica is one full copy of the data living on one machine; a distributed database keeps several so it stays fast and survives failures (Replication and Partitioning).
A partition (in CAP Theorem) means the network dropped messages so some machines temporarily can't talk to each other — not a "table split."
Converge means all replicas end up holding the same value once the chatter catches up.
Commit means a transaction is finalised and its effects are promised to survive.

True or false — justify

TF1. "BASE means the system is never consistent."

False. BASE gives up immediate consistency, not the destination; with no new writes every replica eventually converges to the same value. You lose the timing guarantee, not correctness itself.

TF2. "ACID databases can never be distributed."

False. They can be, using coordination protocols like Two-Phase Commit; the point is that enforcing ACID across machines is slow and blocks on failures, so it's chosen only when correctness must win.

TF3. "In CAP you may sometimes choose to drop Partition tolerance."

False. Partitions are a fact of networking, not a knob you set; you only get to choose between C and A once a partition is already happening.

TF4. "All NoSQL databases are BASE and all SQL databases are ACID."

False. The labels describe guarantees, not the data model — NoSQL Databases like MongoDB offer ACID transactions, and some relational setups run with relaxed consistency.

TF5. "Under BASE, two users can permanently see different like-counts."

False. Differences are transient soft state; once writes stop, background sync forces every replica to the same count. "Permanently different" would violate eventual consistency.

TF6. "Durability just means the data is in RAM after commit."

False. Durability specifically means the committed data survives a crash, which requires it to reach permanent storage (disk/SSD/log), not volatile memory.

TF7. "An AP system will return an error rather than stale data during a partition."

False. That is the CP behaviour. An AP system's whole promise is to answer anyway, accepting possibly stale data over refusing the request.

TF8. "Consistency in ACID and Consistency in CAP mean the same thing."

False. ACID-C means "no rule/constraint is violated by a transaction"; CAP-C means "every read sees the latest write across replicas." Same word, different guarantee — a classic trap.

TF9. "Choosing ACID for one part of an app forces ACID everywhere."

False. Real systems mix per data type: ACID for payments, BASE for the activity feed. You match the guarantee to each data item's cost of being wrong.

TF10. "Isolation guarantees transactions literally run one at a time."

False. It guarantees the result equals some serial order; the engine may run them concurrently as long as the outcome is indistinguishable from a valid sequence (see Isolation Levels).

Spot the error

SE1. "We picked AP, so we never have to worry about conflicting writes."

Error: AP invites conflicts precisely because both sides of a partition accept writes. AP increases conflict handling; you need merge/reconciliation rules, not zero worry.

SE2. "Our bank uses BASE so transfers are super fast and always correct."

Error: BASE trades away immediate correctness. A transfer read from a stale replica could show money that's already spent — exactly the case where ACID's ACID Transactions guarantees are needed.

SE3. "This transaction did the debit but the credit failed, so we'll just leave the debit in."

Error: that violates Atomicity — it's all-or-nothing. The debit must be rolled back so money doesn't vanish; a half-done transaction is never a valid ACID outcome.

SE4. "We're consistent because each machine is internally correct."

Error: per-machine correctness isn't CAP consistency. CAP-C requires all replicas to agree on the latest write; each node can be locally fine yet disagree globally.

SE5. "Eventual consistency means we don't need to store writes durably."

Error: convergence needs the writes to actually exist and propagate. Losing a write means there's nothing to converge to; durability of accepted writes is still required.

SE6. "We got a partition, so we'll turn off partition tolerance to stay consistent."

Error: you can't "turn off" a network failure. During the partition your only real lever is refusing/waiting (favour C) or answering stale (favour A).

SE7. "COMMIT succeeded, then the server crashed, so the write is probably gone."

Error: a successful COMMIT is a Durability promise — the write must survive the crash. If it didn't, the system violated ACID, not "probably lost it."

SE8. "MongoDB is NoSQL, therefore it cannot support atomic multi-document transactions."

Error: modern NoSQL Databases do offer ACID multi-document transactions. NoSQL describes the model, not a ban on strong guarantees.

Why questions

WHY1. Why is Partition tolerance treated as mandatory rather than optional?

Because links between machines will drop packets in the real world; a distributed system that can't survive that isn't usable, so P is assumed and the true trade is C vs A (Distributed Systems).

WHY2. Why does demanding strong consistency on every read hurt scale?

Every read must coordinate with other replicas to confirm it's the latest, so one slow or unreachable node stalls the whole request — throughput and availability drop as the cluster grows.

WHY3. Why is BASE acceptable for a like-count but not a bank balance?

A like-count off by one for two seconds harms no one, while a wrong balance can let money be spent twice. You minimise total cost: choose the guarantee whose failure mode hurts least.

WHY4. Why do ACID systems "block or refuse" during a partition?

They pick CP: if they can't confirm the latest state across replicas, answering could show wrong data, so they wait or reject rather than risk inconsistency.

WHY5. Why is "soft state" listed as its own BASE property?

Because data can change on a replica with no new user input — background sync is actively rewriting it toward convergence. Naming it warns you that a value read now may differ moments later.

WHY6. Why does Isolation exist if Atomicity already protects a single transaction?

Atomicity protects one transaction's own steps; Isolation protects between concurrent transactions so two withdrawals don't both read the same balance and overspend.

WHY7. Why do we say the CAP choice only appears "during a partition"?

When the network is healthy a system can be both consistent and available; the impossibility only bites while messages are being dropped, forcing you to sacrifice C or A.

WHY8. Why can BASE systems return an answer instantly where ACID might make you wait?

A BASE replica answers from whatever it already holds without coordinating, so there's no waiting on other nodes — at the price of possibly serving a slightly old value.

Edge cases

EC1. What happens under eventual consistency if writes never stop?

The guarantee is conditional on write quiescence; with a continuous write stream replicas may never be identical at any instant, though each write still propagates. Convergence is defined for the "no new writes" case.

EC2. Two conflicting writes land on opposite sides of a partition — what does AP do when the partition heals?

Both writes survive the partition, and on healing a conflict-resolution rule (last-write-wins, version vectors, or merge) decides the final value so replicas converge (Eventual Consistency).

EC3. A CP system faces a partition and a read arrives on the minority side — what response is correct?

It should refuse or block that read, since it can't confirm it holds the latest write; returning stale data would break its consistency promise.

EC4. Cost of downtime and cost of wrong data are roughly equal — which contract?

Neither dominates, so the decision rule is inconclusive; you must split by data type or add nuance (e.g. tunable consistency), rather than force one global label.

EC5. A transaction commits, then a rule ("balance ≥ 0") is later violated by a different transaction — did ACID fail?

No. Each transaction is checked at its own commit; ACID-C rejects any single transaction that would break a constraint. A later valid-looking transaction that would violate it is itself rolled back.

EC6. A single-machine (non-distributed) database — does CAP force a C-vs-A trade?

Not meaningfully; with no network between replicas there are no partitions to survive, so a lone node can be strict cheaply. CAP's trade-off is a distributed-systems phenomenon.

EC7. All replicas are already in sync and no writes are happening — is a BASE read as fresh as an ACID read?

Yes, at that moment they agree, so the BASE read returns current data. BASE's weakness only shows around writes and partitions, not in the quiet steady state.

Recall One-line self-check before you leave

Say aloud: "P is not a choice; C-vs-A is the choice, and only during a partition." If that sentence feels obvious, you've internalised the core of both CAP Theorem and BASE vs ACID.