What is Interview Forge?

Interview Forge helps you practice mock interviews, follow study plans, track career goals, review learning analytics, and prepare across 36 pages.

Design Ticketmaster (Ticket Booking) at Google — System Design Interview Guide

The problem at Google

Functional: browse events, view a seat map, hold seats, book and pay, get a confirmation/ticket.
Non-functional: never oversell a seat, holds expire if not paid, on-sales survive huge spikes.
Scale: ~500 events; a popular on-sale sees 100K+ concurrent users for a 10K-seat venue.
Consistency: seat inventory must be strongly consistent — overselling a seat is unacceptable.

Out of scope (covered in detail below)

Refunds, transfers, dynamic pricing, resales, and seat upgrades — deferred and discussed in the dedicated section.

At Google, this problem is framed around algorithmic rigor and generalist problem-solving. Expect Google-specific scale numbers and a focus on production readiness and the company's engineering bar.

Capacity estimation

Resource	Estimate	Notes
Concurrent users (hot on-sale)	100K+	For a 10K-seat venue
Seats	~10K per event	The scarce resource
Hold duration	~5 min	TTL while the user pays
Peak QPS	tens of thousands	Concentrated at on-sale start

Architecture overview

Inventory + hold + booking

+--------+  hold  +-----------+  Lua script  +-----------------+
| Client |------->| Booking   |------------->| Inventory (Redis)|
+--------+        | Service   |              | seat -> state    |
                  +-----------+              +-----------------+
                       |   ^                         |
          hold TTL     |   |  expire/release          v
                       v   |                  +----------------+
                  +-----------+               | Payment Svc    |
                  | Hold Store|               +----------------+
                  +-----------+                        |
                                                       v
                                               +----------------+
                                               | Ticket / DB    |
                                               +----------------+

A Redis-backed inventory with Lua scripts gives atomic hold/expire at high throughput.

Step-by-step request flow

The user selects seats; the booking service atomically moves them from available to held (with a TTL) via a Redis Lua script.
The user pays; on success, the booking service converts the hold into a sold seat and issues a ticket in the DB.
If the user abandons or the hold TTL expires, a background job (or Redis keyspace notification) releases the seats back to available.
A booking idempotency key prevents double-charging on retry.

Unlock the full guide

Premium members get every DSA, system design, company and role interview guide — plus AI practice, mock interviews, and analytics.

Unlock with Premium