Skip to main content

Hotel Booking System

In this chapter we would design a hotel booking system like Airbnb or Booking. Let's first go through functional requirements:

  • Hotel Management System:
  1. Onboarding: This feature would allow hotels to sign up and create an account to manage their properties and rooms.
  2. Updates: This feature would allow hotels to update their information such as property details, room types, and pricing.
  3. Booking: This feature would allow hotels to manage incoming bookings, view guest information, and confirm or cancel reservations.
  • User Booking Portal:
  1. Search: This feature would allow users to search for available properties and rooms based on their desired location and dates.
  2. Book: This feature would allow users to book a room and make payments securely.
  3. Check bookings: This feature would allow users to view their past and upcoming bookings, and make changes if needed.
  • Analytics:
  1. Data-driven insights: This feature would provide the hotel with valuable insights on their operations such as occupancy rates, booking patterns, and revenue.
  2. Reports: This feature would generate reports on various aspects of the hotel's business, such as occupancy rate, room revenue, and booking source.

Now for the non-functional requirements and general ideas how to achieve them we will have:

  • Low Latency: With a large number of users and hotels, it's important to ensure that the system has low latency, meaning that it responds quickly to user requests. This can be achieved by using caching techniques, optimizing database queries, and using fast, reliable infrastructure.
  • High Availability: This means that the system should be up and running and accessible to users at all times, with minimal downtime. To achieve this, the system could be designed with redundancy in mind, using multiple servers, load balancers, and automatic failover mechanisms.
  • High Consistency: Given that many users and hotels will be accessing the system simultaneously, it's important to ensure that data is consistent across the system. This can be achieved through the use of database transactions and version control mechanisms.
  • Scale: With 500k hotels and 10 million rooms, it's important to design the system for scalability, so that it can handle the increased load as the number of users and hotels grows. This could involve using distributed systems, sharding databases, and utilizing cloud-based infrastructure.

image

For the hotel managment endpoints/flow we will have the following components:

  • We use Load Balancer component to uniformly distribute the load coming from users and to redirect user request to the closest (or any other routing algorithm we might use) Hotel Service
  • Hotel Service is interface we use to communicate with the relational database like Mysql and store information about new rooms for example
  • We use CDN (globally distributed cache) to store media like images and videos for the rooms, and store the URL in our relational database so that a user can access the media on CDN directly
  • For each event like a new room has been added we send a event to Kafka cluster, which then propagates it to interested consumers (Note that all communication between different stateless services goes through Kafka cluster)

When it comes to the Search and Book flow we have the following components:

  • Again we use the Load Balancer to distribute the load
  • When a new room is created an event is propagated from Kafka, to Search Consumer which does the update on Elastic which we use for effective fuzzy based search queries.
  • Search Service is an interface we use to access Elastic and perform the search and return the result to the client
  • Booking Service is responsbile for managing all the booking request coming from the users, by storing the data again in releation database cluster (note we have a different cluster from the one used in previous flow, so we can scale them seperately depending on the traffic) and contacting the Payment Service for processing invoices. It also sends a event once the room has been booked to Kafka so it can get propagated to Search Service
  • We use Archive Service to store the bookings information in a Cold Storage so we can free the space in releation database for active bookings, and so we can also perform analysis on the previous bookings via the Spark and Hadoop Cluster.
  • Notification Service is used to notify users on completion of actions like invoice, booking, cancelations and similar

Finally we have the View Bookings flow which contains the following components:

  • As in previous two flow we have Load balancer for load distribution
  • We have Bookings Management Service which sits as interface in front of active bookings in relational database and archived cold storage for past bookings. We also utilize the cache to decrease the load on the active bookings relational database.

All of the stateless service can be scaled horizontally so we can achieve the non-functional requirements, the actual problem is how to scale the databases/storage effectively. To learn more about distrubuted database built on top of Mysql check out the Amazon Aurora which goes in details how to design multi-regions, replicated and partioned databases. It's important to note that the booking operation should be atomic (that's why we choose relational database supporting ACID), and that we should support distributed transactions in order to update all required database rows, and payment processing. To get more infomation on how we can design consistent database with distributed transactions check out Google Spanner. To learn more about transactions and how to prevent common problems like phantom writes and read/write skews check out the Transactions.