Ticketmaster — Naive (SELECT FOR UPDATE)

Every Ticketmaster design interview should start with the naive baseline — not because it works at scale, but because it clearly exposes why it doesn't. SELECT FOR UPDATE is the natural first instinct: the database already guarantees ACID transactions, row-level locks prevent concurrent updates, and you get zero double-booking with zero additional infrastructure. A single PostgreSQL transaction opens, locks the target seat row with SELECT FOR UPDATE, checks status = AVAILABLE, updates to HELD, inserts an order record, and commits. Simple, correct, and immediately comprehensible. The key question is not whether it works at small scale — it does — but where exactly it breaks and why.

The lock hold time problem is the fundamental throughput ceiling. A PostgreSQL SELECT FOR UPDATE transaction holds its row-level exclusive lock for the entire duration of the transaction — typically 50ms including the check, update, order insert, and commit. During those 50ms, any other user attempting to reserve the same seat is blocked in a FIFO queue behind the lock holder. With 200 concurrent users attempting to book the same popular seat (a GA floor position at a Taylor Swift onsale), the last user in the queue waits 200 × 50ms = 10 seconds just for the lock. At this point, connection pool exhaustion cascades: the PostgreSQL connection pool saturates (typically 200 connections), new requests cannot acquire a connection, and the service begins returning 500 errors to all users. This is not a gradual degradation — it is a cliff edge where the system goes from functional to completely unavailable in seconds.

The seat map problem compounds the lock contention. Without any caching layer, every seat map render (GET /api/v1/events/{id}/seats) requires a full-table scan of the seats table filtered by event_id — returning up to 80,000 rows per event. This is not a selective index lookup; it is a sequential read of all seat rows for the event. At 5,000 concurrent seat map views for a single popular event (realistic for an onsale moment where fans refresh constantly), 5,000 concurrent full-table scans compete for the same 200 PostgreSQL connections. Each scan holds a connection for 80-150ms (returning 80,000 rows over the network). Connection pool exhaustion for the seat map query alone prevents any reservation queries from acquiring connections.

Despite these limitations, the naive design has genuine value. For small venues — a comedy club with 200 seats, a fan club presale limited to 500 buyers, an internal company lottery — 50 concurrent buyers is a realistic ceiling and SELECT FOR UPDATE handles it cleanly. The simplicity is not just aesthetic: a system with 4 components (client, load balancer, service, database) has minimal operational surface area. No Redis TTL management, no Kafka lag monitoring, no cache invalidation logic, no async pipeline troubleshooting. A single developer can understand, debug, and operate the entire system. This simplicity is genuinely valuable at the scale it targets.

The naive design reveals exactly what V1 needs to fix. The bottleneck is lock serialisation — but the insight is that named-seat reservation is actually naturally parallel. 60,000 seats = 60,000 independent rows that can all be locked simultaneously without contention between different seats. The problem is not that we are locking; it is that PostgreSQL lock hold time is 50ms while Redis SETNX hold time is 2ms, and that all 60,000 seat locks share one 200-connection PostgreSQL pool. V1 replaces SELECT FOR UPDATE with Redis SETNX per seat key: each SETNX is independent, takes 2ms, and uses Redis's connection pool separately from the database. The 25x latency improvement (50ms → 2ms) plus the elimination of connection pool sharing between locks and reads are the two changes that unlock production-scale ticket booking.

The naive ticket booking system is a four-component linear architecture: BuyerClient → LoadBalancer → TicketService → SeatDB. There is no cache, no async pipeline, no search service, and no separation between read and write paths. This is the minimum viable implementation of a ticket booking system.

All traffic flows from BuyerClient through the LoadBalancer (AWS ALB, 2ms routing latency) to TicketService. TicketService is a monolithic service running on 4 ECS Fargate pods with 50 threads each, handling all four operations: event listing, seat map display, seat reservation, and checkout confirmation. With 200 total threads and 10ms processing time, theoretical throughput is 20,000 RPS — but this number is meaningless because the actual bottleneck is PostgreSQL lock hold time and connection pool saturation.

SeatDB is a single PostgreSQL RDS instance (db.r7g.xlarge, 4 vCPU, 32 GB RAM) with a 200-connection pool. Three tables live here: events (100K rows, read-heavy, B-tree index on city and event_date for filtered browse), seats (80K rows per event, the most contended table), and orders (write-heavy during onsale, one row per reservation attempt).

The reservation flow exposes the serialisation bottleneck directly. TicketService opens a PostgreSQL transaction, executes SELECT FOR UPDATE on the target seat row (seat_id = ?), acquires an exclusive row-level lock, checks status = AVAILABLE, updates status to HELD, inserts an orders row with status = PENDING and expires_at = NOW() + 10 minutes, and commits. Every concurrent attempt on the same seat blocks on the row lock until commit. With 50ms lock hold time and 200 concurrent reservations for the same event's popular seats, lock wait time reaches 10 seconds and connection pool exhaustion follows within seconds.

The seat map query is equally revealing. TicketService executes SELECT * FROM seats WHERE event_id = ? — returning up to 80,000 rows. With no caching, every seat map render holds a PostgreSQL connection for 80-150ms of I/O. At 5,000 concurrent seat map views (realistic for an onsale moment), all 200 connections saturate on seat map reads alone, blocking reservation attempts from acquiring connections entirely. The simulation makes this visible: as load increases past 200 concurrent users, the DB connection pool graph saturates at 200 and response time spikes from 100ms to 2-5 seconds before timing out.

The checkout confirmation flow illustrates the race condition inherent in this design. TicketService processes payment after the initial reservation transaction commits (the lock is released at commit). If another user's SETNX — or in this design, another SELECT FOR UPDATE — succeeds between the initial reserve and the confirm, a race condition opens. This is the fundamental limitation of separating reservation from payment without maintaining the lock: true atomicity would require holding the lock for the entire payment flow, but database transactions must never span external network calls.