System Design of a Hotel Reservation System — Part 3

In the earlier parts, we have covered the design of the hotel side of the marketplace as well as how the customers can search for hotels.

System Design of a hotel reservation system — Part 1

System Design of a hotel reservation system — Part 2

In this post, we will look at the design to support bookings for hotels by customers. Since the bookings will be larger in number and also more frequent, we can expect a higher traffic to this flow.

Let’s assume we expect 100 million monthly active customers globally, and on an average 50 million customers book hotel stays every month. This implies that we will get at least 50 million booking requests every month. Breaking it further down, we can expect around 2 million booking requests per day which translates to ~1400 requests per second on an average. Taking into account the peak bursts, we will need to design our system to handle at least 3x of this load, which means we can expect the peak traffic to be around ~5000 requests per second.

Lets look at the query patterns of the booking data. The booking data will need to be queried as a part of the following flows:

1. User can see a list of past, current and/or future bookings
2. User can modify a booking
3. User can cancel a booking
4. Hotel can see a list of their bookings
5. Hotel can accept/reject a booking
6. Platform admins and analysts can see a list of bookings

The above flows can be classified into the following categories:

1. User flows — 1,2,3
2. Hotel flows — 4,5
3. Analytical flows — 6

To ensure that we maintain the principle of segregation of responsibilities, we will create separate sub systems for each of the above categories.

Let’s look at the user flows now. The 3 flows that we have listed above will need the queries to be made wither by the user ID or the booking ID. Since our queries need to be just made on the 2 keys above, and because we want our system to scale over 5000 requests per second, we can consider using a NoSQL database like Cassandra. Cassandra with its distributed master-master architecture would allow us to scale to the required load and also help us maintain the schema that we need as its a columnar database.

We can use UserID as the primary key (or the partition key) and have the booking ID as the clustering key. This way, we will be able to efficiently run queries and updates on the user booking data. We can visualise a user booking record in Cassandra as follows:

{
  "user_id": "user-uuid",
  "booking_id": "booking-uuid",
  "start_date": "10-10-2023",
  "end_date": "15-10-2023",
  "hotel_id": "hotel-uuid",
  "room_type": "DELUXE"
  "status": "CREATED",
  "payment_id": "payment-uuid"
}

Lets look at the booking flow now. The user journey will look like this:

1. User logs in to the app/website
2. User enters the location, dates and other preference
3. The app shows the user a list of hotels that are available on the given dates and match other preferences
4. User selects a hotel and chooses the room type
5. User makes the payment
6. Booking is confirmed

In order to support this journey, the component diagram would look like the following:

Here we have 5 micro-services:

1. hotel-availability-service: This service takes the requested dates and a list of hotels and filters out the hotels that aren’t available on the given dates.
2. hotel-search-service: This was described in Part 2. This service takes the location or the search query and returns a list of hotels.
3. hotel-reviews-service: This service takes a list of hotels and returns the details of the ratings for those hotels.
4. booking-service: As the name suggests and as explained above, this will be backed by a Cassandra cluster and enable creating reservations.
5. payment-service: This service manages the payments for a requested reservation.

In addition to the 5 microservices listed above, we also have an orchestration service which acts as a layer of abstraction over the above microservices. The orchestration service first queries the hotel-search-service to get a list of hotels relevant to the search term, it then passes this list of hotels to the requests to both hotel-availability-service and hotel-reviews-service in parallel in order to finally collate a list of hotels that are available on the given dates, tagged with their ratings.

The orchestration service sits behind an API gateway which acts as a reverse proxy for the server. Also, all the bookings that are created or modified are also published to the “bookings” topic.

We will cover in detail how the availability and review services will work in future posts.

At this point, we have a system that allows hotels to onboard into the platform and create their offering, and the users to search for hotels in a location and create bookings. In the next part, we will look at how the availability service would be designed to serve the use cases that we have defined in this series of posts. Thanks for reading!

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.