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)

Requirements & scope

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.

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

Ticketmaster — inventory, hold, booking

Hover a node to highlight its connections, or click a node to see its role. A Redis-backed inventory with Lua scripts gives atomic hold/expire at high throughput.

ClientServiceDatastoreCacheQueueExternal

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