Addepar Software Engineer Interview Experience — Ticketmaster Reservations Across Regions and Planets

Addepar Interview - System Design

Question: Design Ticketmaster.

Functional requirements:

• Users should be able to view events.
• Users should be able to search for events.
• Users should be able to book tickets to events.
• The same event has multiple sections at the same venue, and different sections have different prices.
• Checkout has a 10-minute time limit. After the time expires, the ticket must be released.

The interview required designing the core entities first, satisfying the functional requirements, and then discussing scale.

The core entities could include:

• User
• Event
• Venue
• Section
• Seat or Ticket
• Reservation
• Order

A ticket or seat could have several states:

AVAILABLE -> HELD -> SOLD

After a user enters checkout, the ticket is first marked HELD and given a 10-minute expiration time. After successful payment it becomes SOLD; if checkout times out, it is released.

Follow-up:

How would this scale when people in different cities across the United States are all using it?

Hint: This is a read-heavy system where reads greatly outnumber writes.

Services could be deployed in different regions, such as US East, US West, and US Central.

Event queries and searches are mainly read requests, so traffic could be spread through caches, read replicas, and multiple read servers.

Booking is a write request. The ticket inventory for the same event must remain consistent to avoid overselling.

If an event is in another country, how should a request reach the corresponding region?

Requests could be routed according to the event's region.

For example, a user in the United States who buys a ticket to an event in Japan could query through a nearby region, but the actual booking request should be sent to the Japan region. That region would be responsible for the event's ticket inventory.

The event ID could be used to find the region in the event metadata, and a global load balancer, DNS, or another routing layer could forward the request there.

If the event were on another planet and request latency reached several minutes, possibly exceeding 10 minutes, what would happen?

The problem is that network latency might be close to or even longer than the checkout timeout.

The 10 minutes could be defined as the validity period of the server-side reservation rather than the client's local time. When a reservation is created, the event's region would generate expiresAt, and the authoritative region would make the final decision about whether it had expired.

If network latency were extremely high, other options could include extending the checkout window, reserving earlier, processing checkout asynchronously, or establishing a reservation proxy in the user's region.

The key point is that the authoritative region for the event must determine the final state of the ticket inventory and reservation.