Transactions Motivation
Concept. A transaction groups related database operations into one all-or-nothing unit.
Intuition. When millions of Taylor Swift fans hit Ticketmaster at once, each purchase (check the seat, charge the card, mark it sold) must complete entirely or not at all, so no two fans get the same seat. The required guarantees are no duplicate seat sale and no charge without a seat. Under heavy load, queues stalled, sales were delayed, and fans encountered errors. The hard problem is keeping transactions correct and fast under that crush.
Case Study: Taylor Swift’s Eras Tour
Figure: One Buy click is one transaction: three steps, all or noneAlice clicks Buy. That single click is one transaction wrapping three steps: check the seat is open, charge the card, record the sale. The transaction is atomic, so either all three commit together or none of them do, never a charge without a seat. This runs about ten thousand times per second with every fan reaching for the same seats. Color key: violet is the transaction and its commit, red is the all-or-nothing abort.
Figure 1. One fan's Buy click is a single transaction: check the seat is open, charge the card, record the sale, bundled so either all three commit or none do, never a charge without a seat and never the same seat to two fans. Multiply by the on-sale crush, every fan racing for the same seats, and you have the problem this module solves.
The Scale of the Problem
Figure: Taylor Swift’s Eras Tour on saleFour figures from the on-sale: 52 show dates, 3.5 million fans pre-registered, over 2 million tickets sold in a single day, and 3.5 billion system requests in a few hours.
What Went Wrong?
Ticketmaster reported 3.5 billion system requests, four times its previous peak. Sales were slowed or postponed, and validation errors caused fans to lose carted tickets. The database still has to enforce two guarantees: no seat sold twice and no charge without a seat.
Figure: Heavy demand tests availability and correctnessTicketmaster reported 3.5 million registrations, 3.5 billion requests, and four times its previous traffic peak. Queues and purchase flows were disrupted. The required guarantees are no duplicate seat sale and no completed charge without a seat; these are requirements, not an audit of every purchase.
Figure 2. Ticketmaster reported 3.5 million registrations and 3.5 billion system requests, four times its prior traffic peak. Sales were delayed and fans encountered errors. The transaction guarantees are simple: no seat sold twice and no charge without a seat. Keeping those guarantees while staying responsive under load is the problem this module addresses.
How That Compares
Figure: Large workloads need deliberate engineeringVisa reports capacity above 65,000 transaction messages per second. During Prime Day 2022 DynamoDB peaked at 105.2 million requests per second with single-digit millisecond responses. Ticketmaster reported four times its prior traffic peak. The metrics describe different workloads.
Figure 3. Visa reports capacity above 65,000 transaction messages per second. During Prime Day 2022, Amazon DynamoDB peaked at 105.2 million requests per second with single-digit millisecond responses. Ticketmaster reported four times its previous traffic peak. These are different workloads and metrics, but all require deliberate engineering for concurrency and availability.
Growing concurrency
More clients create more overlapping work. Hardware, storage, and indexing choices change with the workload; the requirement to keep each transaction correct remains.
Figure: More writes, the same correctness guaranteesThree illustrative workload tiers. Classic retail systems such as Walmart in the 1990s and 2000s illustrate about ten thousand writes per second. Cloud services such as Gmail and Roblox in the 2010s and 2020s illustrate millions of writes per second. Agent workloads from 2025 onward motivate a target of tens of millions of writes per second with NVMe and distributed compute. These rates are illustrative tiers, not measured throughput attributed to the named services.
| Classic | Modern | Future |
|---|---|---|
| ~1,000s / sec | ~10M / sec | millions of agents / sec |
| B-Trees | LSM Trees | Learned indexes |
Figure 4. Classic retail systems such as Walmart, cloud services such as Gmail and Roblox, and agent workloads from 2025 onward illustrate increasing write demand: about 10,000 writes per second, millions, and a target of tens of millions. These are illustrative scale tiers, not measured rates for the named services. Hardware progresses from disks and a few cores to SSDs and many cores, then NVMe with distributed compute; every tier still needs correct transactions.
What We'll Learn
The four guarantees that make this safe under load, atomicity, consistency, isolation, and durability, are ACID. They start on the next page.