Section 5: One Row per Seat, per Show - Data Modeling

Executive Summary: The data model splits cleanly into what never changes (a venue's seat layout) and what every fan fights over (one inventory row per seat per show). That ShowSeat row carries a status, a hold id and an expiry, and the hold is a single conditional update across the requested rows: all match, or nothing changes. General admission gets a counter instead of rows. Holds, orders and tickets sit beside the inventory, a locked per-account row enforces the 4-ticket limit inside the same transaction, and a unique constraint on (show, seat) in the tickets table is the last guard on the core invariant: a seat is sold at most once.

The interviewer slides the marker across. "You've defined the APIs. Show me the tables, and show me where a seat's truth lives."

You: "I'll start by splitting the data in two. A venue's layout is static: Section 112, Row F, seat 7 is the same chair for every show. Whether that chair is free for show E-7781 changes every second during the on-sale. Those two facts need different homes."

Static Layout vs Per-Show Inventory

The static side is three entities. A Venue owns many Seats, each with section, row, number, map coordinates, an accessibility flag and a price zone. An Event (the artist's tour stop) has one or more Shows, each a date at a venue with an on-sale time. None of this is contended: the layout is what Section 4's seatmap endpoint serves from the CDN for the life of the show. The contended side is the per-show inventory, plus the records a purchase leaves behind.