Before you can compare ACID and BASE, you must be able to picture the tiny building blocks the parent note quietly assumes. We build each one from nothing: what it means in plain words → what it looks like → why the topic needs it.
Picture a table. Each row is a record; each cell is a value.
Look at the highlighted row: the account with id = A is one record, and the number 100 inside it is one value. The whole topic is about what number a reader sees in that cell — and whether every computer agrees on it.
WHY the topic needs it: ACID and BASE are both promises about what value you get back when you read a record. Without the word "value" we cannot even state the question.
Picture a bank transfer. It is really two writes: subtract from A, add to B. A transaction draws a box around both.
Look at the box in the figure: the whole point is that no one is ever allowed to see the moment after the debit but before the credit — because at that instant $50 has vanished from the world.
WHY the topic needs it: the "A" in ACID (Atomicity) is literally a promise about this box. You cannot understand "all-or-nothing" without first seeing the group it applies to.
Picture a pencil draft you can either ink in (commit) or erase completely (rollback) — never leave half-inked.
WHY the topic needs it: "all-or-nothing" is enforced by rollback. If step 2 fails, the database rolls back step 1, so the box from Figure 2 is honoured. See ACID Transactions for the full mechanics.
Picture a fence around the "valid" states: inside the fence is allowed, outside is forbidden.
WHY the topic needs it: the "C" in ACID (Consistency) means every transaction must land you back inside the fence. Without a rule to protect, "consistency" has no meaning.
Picture the difference between a note held only in your head (gone the instant you faint) versus one written in permanent ink on paper that stays after the lights go out.
WHY the topic needs it: it completes ACID — Atomicity, Consistency, Isolation, Durability — the four promises the strict contract makes.
Look at the two overlapping bars. Both users read the same balance of $100 at the same instant, each subtract $50, and each writes back $50 — so the account ends at $50 even though $100 was withdrawn in total. One update was silently lost because the second writer never saw the first writer's result. This single anomaly is called a lost update. On the right, the transactions are forced to line up, so the second one reads the already-updated $50 and correctly writes $0. Forcing that line-up is called isolation (the "I" in ACID); see Isolation Levels for the degrees of strictness.
WHY the topic needs it: without concurrency there is no danger of "stepping on each other," and Isolation would be pointless.
Picture the same notebook photocopied and handed to friends in different cities — each copy is a replica living on its own node. This is the world of Distributed Systems and Replication and Partitioning.
WHY the topic needs it: on a single machine there is only one copy, so it is always self-consistent. Disagreement is only possible once copies exist. BASE only makes sense in this multi-copy world.
Follow the timeline: at t0 someone writes 5 to replica 1; replica 2 still shows 4 (stale) for a moment; by t2 the update has spread and both show 5 (converged). That "eventually the same" is exactly Eventual Consistency — the "E" in BASE.
WHY the topic needs it: "eventual consistency" is a promise about staleness ending. You cannot state it without the words "stale" and "converge."
WHY the topic needs it: BASE spells out Basically Available, Soft state, Eventually consistent — the three promises of the relaxed contract, and the direct opposite of ACID's strictness.
Picture the phone line between two cities going dead: both cities keep working, but they can no longer tell each other about new writes.
WHY the topic needs it: the whole CAP Theorem — the bridge in the parent note — is a statement about what you must give up during a partition. It is the single event that forces the ACID-vs-BASE choice.
WHY the topic needs it: ACID-leaning systems pick CP (keep Consistency, sacrifice Availability); BASE-leaning systems pick AP (keep Availability, sacrifice strong Consistency). These letters are the axis the whole comparison lives on.
Read it top to bottom: a value gives us reads and writes, which bundle into transactions, which (with commit/rollback, durability, constraints and concurrency) power the ACID promise. Meanwhile replicas introduce staleness, which powers the BASE promise. Partitions force the CAP trade-off, and everything meets at the final choice.