Commerce & payments · Advanced

Ticket booking

Ticketmaster-style sales with a virtual waiting room and seat holds that expire on their own.

Every part, and why it is there

Fans

Thousands of fans arrive the second a popular show goes on sale. Most only browse, but everyone wants the same few hundred good seats at once.

Event page CDN

Event pages and seat maps change rarely, so the CDN serves them from the edge. Without it, the browsing crowd alone would flatten the event service on sale day.

API gateway

One front door for search, seat maps and booking. It checks sessions and throttles abusive clients before they reach anything expensive.

Event search

Finds shows by artist, city or date. It is kept apart from booking so a search spike can never slow down people who are paying.

Event index (Elasticsearch)

A search engine copy of the events catalogue, tuned for full-text and filters. It may lag the database by a few seconds, which is fine for discovery.

Event & seat map service

Returns a show and which seats are free. It overlays live holds from Redis on the seat map so fans do not click seats someone else is already paying for.

Virtual waiting room

POST /events/:id/queue puts a buyer in line; the room admits buyers to booking at a rate the system can handle and shows everyone else their place. It turns an uncontrolled stampede into a steady, fair stream.

Booking service

POST /holds places a 10-minute hold on the chosen seats; POST /holds/:id/confirm takes payment and makes the booking final. It is the only component allowed to change who owns a seat.

Seat holds & queue (Redis)

Each held seat is a key set with “only if absent” and a 10-minute expiry. Two buyers cannot both win the key, and an abandoned cart frees its seats automatically when the timer runs out. The waiting room keeps its line here too.

Bookings DB

The durable truth: shows, seats and confirmed tickets. A unique constraint on (show, seat) is the final safety net if a hold ever slips.

Payment provider

Charges the card while the hold is alive. Payment is the slowest step, which is exactly why the seat is held first instead of locked in the database.

Booking events

A confirmed booking is published here so emails and ticket delivery happen after the buyer has their answer, not during it.

Ticket delivery

Generates the mobile ticket and sends the confirmation. If email is slow, tickets still sell.

Email / SMS provider

An external provider that actually delivers the message. Retries are fine because the ticket id makes each send idempotent.

Asked in interviews at

  • meta
  • google
  • amazon
  • microsoft
  • apple
  • agoda
  • circle

Concepts used here

  • Database indexes: Find one user among a million by reading 4 pages instead of 12,500. Build the index by hand, then see what it costs and why column order matters.
  • CAP theorem: When the network between two copies of your data breaks, each side must either refuse some requests or risk a wrong answer. You choose which, ahead of time.

Learn more

All system design examples