ACID and BASE database properties

01What ACID promises within a boundary

Transfer $40 from account A to B. Initially A has $100 and B has $20. A successful transfer should leave both at $60; it must not save only the debit or allow concurrent spending to violate the balance rule.

ACID describes four transaction properties:

• Atomicity: the required changes commit together or none commit. Saving only A's debit is insufficient.
• Consistency: correct transaction logic and database constraints preserve declared rules, such as equal debit/credit and no negative balance.
• Isolation: a defined rule controls how concurrent transactions interact. Some levels prevent more interference than others.
• Durability: once the database reports commit success, it preserves that commit through the failures covered by its configuration.

Name the records covered. A transaction in the account database does not automatically include an email provider, another unrelated store or every replica's visible read state.

02BASE describes a tendency, not a universal API

Follow the difference between a money record and its display feed:

1. The account transaction updates balances and saves its outcome. These records must preserve the transfer rule together.
2. A separate activity feed receives the committed event later. The balance can be correct while the feed still shows the old display.
3. The feed catches up or is repaired. The product may permit that delay, but it does not permit an incomplete debit/credit commit.

This explains two meanings of consistency. ACID consistency concerns declared record rules. Replica consistency concerns which saved version a read can observe across copies.

BASE is commonly expanded as basically available, soft state and eventual consistency. It describes a tendency toward serving through some disruptions and letting copies converge, not one precise API:

• The feed may remain usable while updates are delayed.
• Its displayed state can change as old pending events arrive, even without a new user action; this is the idea behind soft state.
• Local ACID account transactions can coexist with that delayed feed.

Also name isolation and acknowledgment settings. Serializable isolation makes concurrent transactions behave like some one-at-a-time transaction order. A weaker transaction level may allow races. Durable commit settings determine which saved copies exist when success is returned; a log or replica count by itself does not promise survival of every machine, regional or operator failure.

03Worked example: transfer and activity feed

Call the customer's one transfer request T8 so a retry can identify it.

1. Verify permission, amount and T8. Look for an existing matching request result; reject changed content under the same request identity.
2. Protect the balance check and updates. A transaction can lock the account rows or detect conflicts, then calculate A=$60 and B=$60. Their combined $120 remains unchanged.
3. Commit both balances, T8's result and pending feed work together. A unique request-identity constraint prevents concurrent T8 attempts creating two transfer outcomes. The pending event is an outbox record. A failure before commit cannot leave only the debit as a completed transfer.
4. Return success after commit. If the response is lost, a matching T8 retry returns the saved transfer outcome rather than moving another $40.
5. A relay sends the saved feed event later. It can retry, and the feed recognizes repeated events. The relay's network send is not part of the local balance transaction.

Now start two $80 transfers that both read A=$100. Independent prechecks followed by unconditional writes are unsafe: both could act on the same old value. For example, lock the account row while checking and deducting. The first $80 transfer leaves $20; the second then reads $20 and rejects an $80 spend. Checking $100 outside that protected change would not enforce this rule. A serializable transaction may abort when conflicts make a safe commit impossible; retry the whole safe transaction, not merely its last statement.

Do not send irreversible email or payment effects during an attempt that may abort and retry unless that external service can resolve repeats safely. Rolling back local records cannot unsend an accepted email. The outbox saves the obligation to send without pretending the provider joined the transaction.

04Name the guarantees instead of choosing a slogan

Choose guarantees for each operation:

• Balance movement: show the records and concurrent checks preserving the monetary rule.
• Activity display: state its permitted delay, saved update work, repeated-event handling and repair path.
• Commit success: name which independent durable copies must contain the write and which losses they cover.
• Database family: read actual transaction and read guarantees. Some nonrelational stores support ACID transactions; some relational deployments serve old replica reads.
• External side effects: identify the provider's repeat-recognition or status-query mechanism, or honestly state duplicate tolerance.

A slogan cannot answer these questions. Explain the before/after balances, one overlapping transfer, a lost response and a delayed feed. They show how strong local record correctness and weaker display freshness can coexist without weakening the transfer itself.