Design an Event Ticketing Platform With Seat Holds and High-Demand On-Sales

Quick Overview

A technical system design prompt for product managers: design a ticketing platform like Ticketmaster for finding events, choosing seats and paying. It tests requirements, data modeling, seat holds that prevent double selling, handling huge on-sale traffic spikes, and product trade-offs around bots and fairness.

Design an Event Ticketing Platform With Seat Holds and High-Demand On-Sales

Company: Google

Role: Product Manager

Category: System Design

Difficulty: medium

Interview Round: Other

In a technical interview for a product manager role, you are asked to design a ticketing platform like Ticketmaster: the service people use to discover live events, choose seats and pay for tickets. Walk through the requirements, the main components and data, and the hardest technical problems the platform has to solve. ```hint Find the hard part Browsing events is a read-heavy problem that caching handles well. Spend most of your time on the moment a very popular event goes on sale, when far more people want seats than exist. ``` ### Clarifying Questions - Is the scope primary ticket sales only, or also fan-to-fan resale and ticket transfers? - Are events mostly reserved seating with a seat map, general admission, or both? - What peak should the design handle: how many fans might try to buy for a single stadium show at the moment it goes on sale? - How much weight should fairness to fans carry against selling out quickly, for example in how the queue orders people and how bots are handled? ### What a Strong Answer Covers - Functional and non-functional requirements, separating strict consistency for seat inventory from availability for browsing. - A data model and booking flow with temporary seat holds that expire, and a mechanism that guarantees a seat is never sold twice. - A plan for on-sale traffic spikes that protects the inventory and payment services, with rough estimates behind it. - Payment and failure handling: idempotent checkout, hold expiry, payment provider outages, and reconciliation. - Product trade-offs a PM owns, such as fairness, bot defense and purchase limits, plus the metrics that show an on-sale went well. ### Follow-up Questions - A fan's payment succeeds just after their seat hold expired and another fan has taken the seat. What should happen, and how would you make it rare? - How would you design the queue so that fans who arrive before the sale opens are treated fairly and bots gain no edge? - Which metrics would you watch live during a major on-sale, and which would make you pause it?

Overview: A technical system design prompt for product managers: design a ticketing platform like Ticketmaster for finding events, choosing seats and paying. It tests requirements, data modeling, seat holds that prevent double selling, handling huge on-sale traffic spikes, and product trade-offs around bots and fairness.

Google logo
Google
Aug 20, 2025
mediumProduct ManagerOtherSystem Design
0
0

In a technical interview for a product manager role, you are asked to design a ticketing platform like Ticketmaster: the service people use to discover live events, choose seats and pay for tickets. Walk through the requirements, the main components and data, and the hardest technical problems the platform has to solve.

Clarifying Questions Guidance

  • Is the scope primary ticket sales only, or also fan-to-fan resale and ticket transfers?
  • Are events mostly reserved seating with a seat map, general admission, or both?
  • What peak should the design handle: how many fans might try to buy for a single stadium show at the moment it goes on sale?
  • How much weight should fairness to fans carry against selling out quickly, for example in how the queue orders people and how bots are handled?

What a Strong Answer Covers Guidance

  • Functional and non-functional requirements, separating strict consistency for seat inventory from availability for browsing.
  • A data model and booking flow with temporary seat holds that expire, and a mechanism that guarantees a seat is never sold twice.
  • A plan for on-sale traffic spikes that protects the inventory and payment services, with rough estimates behind it.
  • Payment and failure handling: idempotent checkout, hold expiry, payment provider outages, and reconciliation.
  • Product trade-offs a PM owns, such as fairness, bot defense and purchase limits, plus the metrics that show an on-sale went well.

Follow-up Questions Guidance

  • A fan's payment succeeds just after their seat hold expired and another fan has taken the seat. What should happen, and how would you make it rare?
  • How would you design the queue so that fans who arrive before the sale opens are treated fairly and bots gain no edge?
  • Which metrics would you watch live during a major on-sale, and which would make you pause it?