Problem Statement

Build a platform like TicketMaster where users can browse available seats from events, select tickets, and make purchases. The system should handle high traffic, especially during popular event releases. We have two design goals:

• The system must be able to scale indefinitely.
• It’s minimal viable.

User flow

We will assume the user client is a web app and design the ticket booking experience by three flows.

1. User view available seats from a given event

Illustration for user flow #1

                              Illustration for user flow #1

1. The user choses one of the available seats and requests to book it. The user browser is directed to a third party payment processor – we will assume Stripe for easier discussion – where the payment happen. In the meantime, our service should hold this seat for the user – no other users can book it.
2. Our system receives the payment processing result from Stripe and update our storage state accordingly; then our system notifies the user of the booking result. User notification is out of scope but leave here for completeness).

Illustration for user flow #2 and #3

                              Illustration for user flow #2 and #3

Identify hard questions

Our system allows concurrent booking on the same event and the same seat. Race conditions could lead to inconsistencies. We will address the following hard questions of this design

• Avoiding double booking. A user can’t pay to book a seat that’s already booked or under hold state.
• Expiring hold status correctly. If a user requested to book but didn’t pay on Stripe in time, we need to lift the hold status on the given seat so that other users can book it. We also need to deal with the situation where the payment success notification reached our service after we’ve lifted the hold and the seat is booked by another user, which as we will see, is inevitable.
• We can’t lose any payment success notification. Our server has down time but it can’t miss any payment result update from Stripe, otherwise, a user will pay but we don’t give her the seat. It’s an unacceptable user experience.
• Fast response speed on seat view requests (flow #1). Users have must lower speed tolerance on read operations than write ones. Therefore our system must return the list of seat status for a given event_id fast. We can tolerate eventual consistency – booked seats may be returned as available – as long as it doesn’t lead to double booking.

System Architecture

We will describe the system by how the three flows, mentioned above, are served.