Transactions Motivation
Concept. A transaction is a multi-step database operation that must run as if it were a single atomic unit, even when thousands of other transactions are running on the same data simultaneously.
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. That guarantee held. What buckled was the load around it: queues froze, sales were paused, payments timed out. The hard problem is keeping transactions correct and fast under that crush.
Case Study: Taylor Swift Concert Sales on Ticketmaster
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
What Went Wrong?
The popular story is that Ticketmaster double-booked seats. It did not. The transactions did their job: no seat went to two fans, the bots walked off with zero tickets, and 2.4 million tickets sold in a single day, a record. What broke was everything around that guarantee, under four times the load the site had ever seen.
Figure 2. The real failure was load, not correctness. About 12 million visitors and scalper bots drove 3.5 billion requests, four times the prior peak (violet). Under it, availability bent: queues froze thousands deep, Ticketmaster throttled and paused sales to stay up, and seat holds and payments timed out (red). But the transactions held: no seat sold twice, bots got nothing, and a record 2.4 million tickets sold in a day (green). Keeping that correctness while also staying fast under the crush is the problem this module solves.
How That Compares
Figure 3. Other systems clear far more, every day, without melting. Visa settles 100,000 transactions a second at peak; Amazon answers 105 million requests a second on Prime Day in under ten milliseconds. Ticketmaster fell over at four times its own prior record. The lesson is not that transactions are slow. It is that absorbing a sudden, massive spike of concurrent load takes the kind of engineering Visa and Amazon built over decades, and a one-off flash on-sale had not.
The 100× Scale
The whole stack moves together. Concurrency, hardware, and the data structures underneath each jumped by orders of magnitude per generation. The challenges you will solve sit on top of all three.
Figure 4. Each generation runs roughly 10,000 times the load of the last (about 100× per decade), and concurrency, hardware, and data structures all jump together. The classic era ran thousands of transactions a second on disks and B-Trees; the modern era runs tens of millions on solid-state and LSM Trees; the agent era stacks a third jump on top, and has to hold the same correctness guarantees the classic era did.
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.