Designing Ticketmaster

1Understanding the Problem

Functional requirements

Prioritize the top three "users should be able to…" statements; note the rest below the line. The video derives them by walking the user flow backwards: to book you must view an event; to view it you must first search for it.

1. Users can view events (details + seat map).
2. Users can search for events.
3. Users can book tickets to events.

Below the line: viewing one's booked events, admin/event-coordinator flows (adding events), and dynamic pricing for popular events.

Non-functional requirements — the interesting part

2Core Entities & the API

Approach: build up sequentially through the functional requirements; then let the non-functional requirements drive the deep dives. Start with the entities (the nouns / persisted data), then the API.

2.1 · Booking is a two-phase process

// View — returns everything to render the event page + seat map
GET /events/:eventId -> Event & Venue & Performer & Ticket[]

// Search — all optional filters
GET /events/search?keyword&start&end&pageSize&page -> Event[]

// Book — simple to start...
POST /bookings/:eventId  { ticketIds: string[], paymentDetails }  -> bookingId

// ...evolves into two phases:
PUT   /bookings/reserve  { ticketId }              // reserve for 10 min
PATCH /bookings/confirm  { ticketId, paymentDetails }

3High-Level Design

Microservices behind an API Gateway (routing + auth + rate limiting). Walk the three requirements in order.

3.1 · View, search, book

View. The Event Service reads the event, venue, performer (a join) plus the event's tickets (to render the seat map) and returns them.

Search. The simplest possible version is a SQL LIKE query — which the instructor flags immediately as slow (full table scan) and defers to the search deep dive.

-- works, but sucks: wildcard forces a full table scan
SELECT * FROM Events
WHERE name LIKE '%Taylor%' OR description LIKE '%Taylor%'

Book. Needs a transactional DB. The write-up picks PostgreSQL (any ACID store — MySQL, DynamoDB — would do) and will add isolation + row locking / OCC to prevent double bookings.

3.2 · Why one shared database (not one per service)

4Deep Dive · Reserving Tickets (the crux)

We need to (a) lock a ticket while the user checks out, (b) release it automatically if they abandon, and (c) mark it sold on success. Four approaches, worst to best.

4.1 · The solution ladder

BadLong-running database locks (SELECT FOR UPDATE)

Lock the ticket row inside an interactive transaction held open for the whole ~5-minute checkout.

GoodStatus + expiration timestamp, released by cron

Give each ticket a status — available / reserved / booked — and a reserved_timestamp. On reserve, flip to "reserved" and record the time. A cron job periodically flips expired "reserved" rows back to "available."

GreatImplicit status via short transactions

Recognize a ticket's true status is "available OR (reserved but expired)." Use short transactions (not long locks) that check-then-set:

BEGIN;
  -- reserve only if AVAILABLE or (RESERVED and expiration < now)
  UPDATE tickets
     SET status='reserved', expiration = now() + interval '10 min'
   WHERE id = ? AND (status='available' OR expiration < now());
COMMIT;

This guarantees only one user reserves a ticket and lets users claim expired reservations instantly — no cron in the critical path. Cost: reads must filter on two fields (partly solved by a compound index / materialized view), and the table is less legible. A sweep job can still tidy stale rows, but crucially the system stays correct even if that sweep is delayed.

GreatDistributed lock with TTL (Redis)

On reserve, set a Redis key ticketId → userId with a 10-minute TTL. On confirm, update the DB to "booked" and release the key. If the user vanishes, the TTL expires the key automatically and the seat frees itself. The Ticket table now needs only two states — available and booked — with reservations living entirely in Redis.

# Atomic acquire — only one client wins the key
SET ticket:{id} {userId} NX EX 600

4.2 · The full booking flow (with Stripe)

1. User selects a seat → POST /bookings with the ticketId.
2. Booking Service locks the ticket in Redis (TTL 10 min) and writes a booking row with status in-progress; returns a bookingId and routes to the payment page. (Abandon here → lock auto-releases in 10 min.)
3. Client tokenizes card details with Stripe.js (server never sees raw card numbers — PCI compliance) and sends the token + bookingId; server creates a Stripe PaymentIntent.
4. Stripe processes asynchronously and calls back via webhook on success.
5. The webhook runs a DB transaction: ticket → sold, booking → confirmed.

5Deep Dive · Scaling the View Path to Millions

When tickets drop, thousands refresh the same event page. Handle it with caching + load balancing + horizontal scaling.

6Deep Dive · Keeping the Seat Map Live

After the page loads, the seat map goes stale — users click seats that are already gone and get errors. We need real-time updates.

GoodPush updates — long-polling or SSE

The write-up reaches for Server-Sent Events (SSE): a one-way, persistent server→client channel that pushes "seat taken" as soon as it happens.

6.1 · GreatVirtual waiting queue for mega-events

7Deep Dive · Fast Search

The naive LIKE '%...%' forces a full table scan. Improve it in stages.

GoodIndexes & query optimization

Index the columns used in search (event name, date, performer, venue location); use EXPLAIN, avoid SELECT *, use LIMIT, prefer UNION over OR. Limit: standard indexes are weak for partial-string matches like "Taylor" inside "Taylor Swift," and indexes slow writes.

GreatFull-text indexes in the database

Postgres has built-in full-text search (tsvector + GIN indexes); MySQL has its own. These beat LIKE scans for term matches. (Neither uses Lucene — that's Elasticsearch.) Cost: more storage, harder to maintain.

GreatElasticsearch + CDC

Keep Postgres as the source of truth and sync changes into Elasticsearch. Two ways: write to both in application code (handle partial-write failures/retries), or use Change Data Capture (CDC) — stream DB changes to a consumer that updates Elasticsearch.

Speeding up repeated queries

For popular searches ("Taylor Swift"), cache results — but only because this system does no personalization (everyone gets the same results for the same query). Options, from the video:

• Elasticsearch / OpenSearch node query cache — caches the top ~10K queries per shard (LRU); often just a config flag.
• Redis/Memcached on a normalized search term → results, with invalidation on updates.
• CDN caching the search API response for ~30–60s — wicked fast for hot terms and geographically close.

8What's Expected at Each Level

★Active Recall

↺Quick Revision