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 defines four guarantees for a transaction.

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

Alice checks inventory, authorizes the card, and records the sale. Success commits pending database changes; a declined card triggers rollback, leaving no confirmed ticket or completed charge.

Figure 1. Alice’s purchase checks inventory, requests card authorization, and records the sale. The database commits its pending changes together or rolls them back on failure. A declined authorization leaves no confirmed sale or completed charge. Coordination with the external payment network is application logic; a database rollback alone cannot reverse an external charge.

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

Four cards distinguish each ACID guarantee from a concrete ticket-purchase example.

Figure 2. Each card separates a guarantee from its ticket-purchase example: 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:

  • T1 · Move: Alice transfers $100 to Bob (11:59:59 PM)

  • T2 · Interest: Bank adds 6% monthly interest to both accounts (12:00:00 AM)

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

T1 moves $100 from Alice to Bob; T2 adds 6% interest. Time runs downward in two schedules: without isolation T2 reads a half-finished transfer, ending at $324; with isolation T2 waits for T1 to commit, ending at $318.

Figure 3. T1 moves $100 from Alice to Bob; T2 adds 6% interest to both accounts. Read each schedule downward, with a separate lane for each transaction. Without isolation, T1 credits Bob before debiting Alice, so T2 sees $400 and adds $24 of interest; T1 then finishes, leaving $324 (red), including $6 in excess interest. With isolation, T2 waits for T1 to commit and sees the settled $300, adding the correct $18 and leaving $318 (green).

Isolation makes concurrent transactions appear sequential

In this schedule, the interest transaction waits for the transfer to commit. It calculates interest on the settled $300, so the transfer preserves the principal and only the legitimate $18 of interest is added.


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.