ACID Properties
A transaction gives you a unit of work bigger than one statement, the thing the Ticketmaster scale problem demanded. ACID is the contract that unit signs.
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
Figure 1. Alice's purchase is one transaction around three steps: check inventory, verify the card, complete the sale. Atomicity binds them. All three commit as a unit, or a single failure rolls every one of them back, so a sale is never confirmed against a declined card or sold-out seats.
Atomicity is only the first guarantee Alice's purchase needs. She must not be charged for sold-out seats (consistency), her seat must not be sold to two fans at once (isolation), and her confirmed purchase must survive a crash (durability). Here are all four.
ACID for Data Trust
Figure 2. The four guarantees, one color per letter (the same circle reused on every ACID figure in the module). Each is a rule plus what it looks like when Alice buys a ticket: a declined card rolls back cleanly (atomicity), seats and revenue move as one (consistency), Alice locks the last seat so Bob waits (isolation), and a confirmed ticket survives a crash (durability).
Drop any one of the four and a specific failure follows. Case Study 4.1 walks all four end to end at Stripe; the next example makes one concrete, how dropping isolation lets a bank create money from nothing.
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
Figure 3. Two transactions race at month-end from the same start state: Alice $200, Bob $100, total $300. On the left (red), the transfer credits Bob first, so Bob already shows $200 while Alice is not yet debited and still shows $200; the interest job reads that half-done state and pays 6% on $400, the moving $100 counted twice, and the books end at $324, with $6 created from nothing. On the right (green), the interest job waits on the transfer's lock, reads the settled $300, and ends at the correct $318, exactly $18. The deeper point: isolation makes concurrent transactions appear sequential, as if the interest job simply ran after the transfer, so total money is conserved.
Isolation makes concurrent transactions appear sequential
Isolation forces the interest job to run as if it followed the transfer, never alongside it. The invariant the interleaving broke, total money conserved, holds again.
Summary: ACID = Trust
From the definition to a real system
ACID is the contract that turns stored bytes into a system you can trust with money. Case Study 4.1 watches all four guarantees hold at once inside a single Stripe payment, at a trillion dollars a year.