ACID Properties

Concept. ACID names four guarantees that turn a sequence of database writes into a transaction: Atomicity (all-or-nothing), Consistency (no broken invariants), Isolation (concurrent transactions don't see each other's partial work), and Durability (committed work survives crashes).

Intuition. When Mickey buys Premium, Atomicity ensures the charge and the is_premium = true flag both happen or neither does; Consistency ensures his balance never goes negative; Isolation ensures Minnie's concurrent renewal doesn't leave Mickey's transaction reading her half-written charge; Durability ensures that if the server crashes a millisecond after Mickey gets the receipt, the upgrade still survives.

Example: Transactions in a Ticketmaster-like App

Alice's Ticket Purchase Flow

For Alice's purchase, we need to:

1. Check Inventory

Are there enough tickets available?

2. Verify Payment

Does Alice's credit card authorize the purchase?

3. Complete Sale

Confirm sale, process payment, update inventory

User + Seller Expectations

All three steps need to happen. Or none at all.

Perfect execution or complete rollback. Nothing in between.

What We Can't Allow

  • Confirm sale to Alice if her credit card declines
  • Confirm sale if there aren't enough tickets
  • Sell Alice's tickets to another fan at the same time
  • Lose Alice's purchase data due to system crashes

ACID for Data Trust

Atomicity: All or Nothing

Concept. Either the entire transaction occurs or none of it does, leaving the system in a consistent state. No partial transactions allowed.

Intuition. Alice tries to buy two tickets. If her card declines, no tickets are issued, no payment is processed, no inventory is reduced. The system returns to its original state. If payment works, all three steps complete atomically together.

Consistency: Valid State Always

Concept. The database remains accurate and obeys its integrity rules through every transaction. Constraints, invariants, and totals always hold.

Intuition. Before Bob's purchase: 100 tickets available, SoldRevenue = $25,000. After: 99 tickets available, SoldRevenue += $75. The two numbers stay in sync because the transaction updated both as one unit; the database never shows a state where one moved without the other.

Isolation: No Interference

Concept. Concurrent transactions don't see each other's partial work; each one acts as if it ran alone.

Intuition. Alice and Bob both reach for the last ticket at the same instant. Alice selects → the system locks the row. Bob tries → blocked. Only Alice can complete the purchase; the lock releases when she does (or her 5-minute timer expires). No double-sale, no partial state visible to either of them.

Durability: Survives Crashes

Concept. Once a transaction commits, its changes persist. Even through process crashes, storage failures, or datacenter power loss.

Intuition. Bob buys a ticket and sees the receipt. The server crashes a millisecond later. After recovery, Bob's ticket is still in the database. It cannot be resold, and Bob can prove the purchase at the venue.

Without ACID: What Goes Wrong

No Atomicity

  • Alice's payment fails but tickets are issued
  • Inventory decreases but no payment processed
  • Half-completed transactions everywhere

No Consistency

  • Shows -50 tickets left when only 10 are left
  • Users have tickets for cancelled concerts
  • Money totals don't add up

No Isolation

  • Alice and Bob both get the same seat
  • Double-booking chaos at the venue
  • Angry fans, angry artists, angry everyone

No Durability

  • Bob's ticket disappears after system crash; resold
  • Can't prove purchase at the venue
  • Zero trust in the platform

Example 2: Banking Transfer Race Condition

Scenario: At midnight on the last day of the month, two things happen simultaneously:

  • TransferTxn: Alice transfers $100 to Bob (11:59:59 PM)

  • InterestTxn: Bank calculates 6% monthly interest on all accounts (12:00:00 AM)

Initial State: Alice has $200, Bob has $100. Total money in system: $300

− Without ACID Isolation

Bad Sequence: Money Created from Nothing!

Step 1: TransferTxn reads Alice=$200 ✓
Step 2: InterestTxn reads all accounts
       Alice: $200, Bob: $100
Step 3: TransferTxn credits Bob
       Bob: $100 → $200
Step 4: InterestTxn sees mid-transaction state
       Alice: $200, Bob: $200 (total: $400!)
Step 5: InterestTxn applies 6% increase
       Alice: $200 → $212, Bob: $200 → $212
Step 6: TransferTxn debits Alice
       Alice: $212 - $100 = $112

**Final Result:** Alice=$112 + Bob=$212 = $324 (System incorrectly created $6)

+ With ACID Isolation

Good Sequence: Money Conservation Maintained

Step 1: TransferTxn starts and runs to completion
Step 2: Transfer executes atomically
       Alice: $200 → $100
       Bob: $100 → $200
Step 3: TransferTxn commits
Step 4: InterestTxn starts after transfer completes
Step 5: InterestTxn reads current state
       Alice: $100, Bob: $200 (total: $300)
Step 6: InterestTxn applies 6% increase
       Alice: $100 → $106, Bob: $200 → $212

Final: Alice=$106 + Bob=$212 = $318
✓ Correct! Exactly 6% of $300 = $18 interest

Key Insight: Isolation Makes Concurrent Transactions Appear Sequential

Without isolation, operations interleave and violate business rules (like conservation of money).

With isolation, concurrent transactions execute as if they ran one after another, maintaining consistency.

Summary: ACID = Trust

ACID Properties Enforce Correctness

ACID isn't just theory. It's the underlying foundation that lets us trust database systems with actual money.