ACID Properties

The Four Guarantees Every Transaction Needs 🤝

Transactions are like a handshake - an exchange of money for tickets. Both sides need to trust that the deal will work exactly as expected.

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 ⚛️

📚 Technical Definition

⚛️ Atomicity: All or Nothing

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

🎭 Real-World Example

Alice's Payment Scenario

Payment declined: Two tickets NOT issued, payment NOT processed, inventory NOT reduced → system returns to original state

Payment works: All steps complete atomically together

Consistency: Valid State Always ✅

📚 Technical Definition

✅ Consistency: Valid State Always

System remains accurate and the "source of truth" for all users. Database integrity rules and constraints are always maintained.

🎭 Real-World Example

Bob's Purchase Updates

Before: 100 tickets available; SoldRevenue = 25,000$

After: 99 tickets available; SoldRevenue += 75$

Database accurately reflects the transaction and maintains valid state

Isolation: No Interference 🔒

📚 Technical Definition

🔒 Isolation: No Interference

Each transaction is independent of others, preventing conflicts. Concurrent transactions don't interfere with each other.

🎭 Real-World Example

Alice vs Bob: Last Ticket

Alice selects ticket: System locks it

Bob tries to select: System blocks Bob's access

Result: Only Alice can complete purchase, preventing double-selling. (Released when Alice does not buy or Alice's timer expires in 5 minutes.)

Durability: Survives Crashes 💾

📚 Technical Definition

💾 Durability: Survives Crashes

Once complete, changes persist even with system failures. Committed transactions are permanently stored and recoverable.

🎭 Real-World Example

Bob's Ticket Survives Everything

Transaction complete: Bob buys ticket

System crashes: Server reboots, SSD fails, Martians blow up datacenter

After recovery: Bob's ticket data still there → cannot be resold

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:

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: Alice=$112 + Bob=$212 = $324
💸 $6 created from thin air!

✅ 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 Build Trust in Your Database

Without ACID, transactions are just wishes. With ACID, they're guarantees you can build billion-dollar businesses on.