Case study: Ticket booking (Ticketmaster)

Why does ticket booking split purchase into Phase 1 (a 5-minute temporary seat hold) and Phase 2 (payment confirmation), rather than charging the credit card first and assigning a seat afterward?

A stadium has 50,000 seats, and each seat row is 128 bytes. Roughly how large is the entire event's seat table?

Why is it acceptable to cache `GET /v1/events/{id}/seats` for 2–5 seconds even though a seat might be taken during those 2 seconds?

What happens if the API executes `SELECT remaining FROM seats WHERE seat_id = 1`, checks `if (remaining == 1)` in application code, and then runs `UPDATE seats SET remaining = remaining - 1 WHERE seat_id = 1`?

User A's 5-minute seat hold (`holdToken = 7`) expires at 10:05:00 while User A's credit card charge is still in flight. At 10:05:01 User B holds the same seat (`holdToken = 8`). At 10:05:02 User A's card charge succeeds. How does the system prevent double-selling the seat?

Why is a single-threaded in-memory state machine (actor) per event viable for stadium ticket booking?

In the `hot-event` scenario, 100 fans try to hold Seat 1 at the same time; 1 gets `200 OK` and 99 get `409 Conflict`. Why is `409 Conflict` a success of the architecture rather than a bug?

Why combine lazy expiry (`WHERE status = 'AVAILABLE' OR (status = 'HELD' AND hold_expires_at < NOW())`) with an active background expiry worker?