Understand the Problem
In this chapter, we design a hotel reservation system for a hotel chain such as Marriott International. The design and techniques used in this chapter are also applicable to other popular booking-related interview topics:
-
Design Airbnb
-
Design a flight reservation system
-
Design a movie ticket booking system
Step 1 – Understand the problem and establish design scope
The hotel reservation system is complicated and its components vary based on business use cases. Before diving into the design, you should ask the interviewer clarification questions to narrow down the scope.
What is the scale of the system?
Let’s assume we are building a website for a hotel chain that has 5,000 hotels and 1 million rooms in total.
Do customers pay when they make reservations or when they arrive at the hotel?
For simplicity, they pay in full when they make reservations.
Do customers book hotel rooms through the hotel’s website only? Do we need to support other reservation options such as phone calls?
Let’s assume people could book a hotel room through the hotel website or app.
Can customers cancel their reservations?
Yes.
Are there any other things we need to consider?
Yes, we allow 10% overbooking. In case you do not know, overbooking means the hotel will sell more rooms than they actually have. Hotels do this in anticipation that some customers will cancel their reservations.
Since we have limited time, I assume the hotel room search is not within the scope. We focus on the following features.
-
Show the hotel-related page.
-
Show the hotel room-related detail page.
-
Reserve a room.
-
Admin panel to add/remove/update hotel or room info.
-
Support the overbooking feature.
Sounds good.
One more thing, hotel prices change dynamically. The price of a hotel room depends on how full the hotel is expected to be on a given day. For this interview, we can assume the price could be different each day.
I’ll keep this in mind.
Next, you might want to talk about the most important non-functional requirements.
Non-functional requirements
-
Support high concurrency. During peak season or big events, some popular hotels may have a lot of customers trying to book the same room.
-
Moderate latency. It’s ideal to have a fast response time when a user makes the reservation, but it’s acceptable if the system takes a few seconds to process a reservation request.
Back-of-the-envelope estimation
-
5000 hotels and 1 million rooms in total.
-
Assume 70% of the rooms are occupied and the average stay duration is 3 days.
-
Estimated daily reservations: (1 million * 0.7) / 3 = 233,333 (rounding up to ~240,000)
-
Reservations per second = 240,000 / seconds in a day = ~3. As we can see, the average reservation transaction per second (TPS) is not high.
Next, let’s do a rough calculation of the QPS of all pages in the system. There are three steps in a typical customer flow:
-
View hotel/room detail page. Users browse this page (query).
-
View the booking page. Users can confirm the booking details, such as dates, number of guests, payment information before booking (query).
-
Reserve a room. Users click on the “book” button to book the room and the room is reserved (transaction).
Let’s assume around 10% of users reach the next step and 90% of users drop off the flow before reaching the final step. We can also assume that no prefetching feature (prefetching the content before the user reaches the next step) is implemented. Figure 1 shows a rough estimation of what the QPS looks like for different steps. We know the final reservation TPS is 3 so we can work backwards along the funnel. The QPS of the order confirmation page is 30 and the QPS for the detail page is 300.
Finished reading?
Mark it complete to track your progress.