System requirements

Functional:

1. Users should be able to view the hotel.
2. Users should be able to see the details of the hotel, and room details.
3. Users should be able to make a reservation.
4. Users should be able to cancel and reschedule their reservation.
5. Users should be able to fetch details of their reservation.

Non-Functional

1. We need high concurrency to account for the peak season queries, which can be large.
2. The reservation click through for checking the details of hotels, rooms should be fast .

Capacity estimation

1. Let's assume there are 5000 hotels, and 1 million rooms.
2. 70% of the rooms are occupied.
3. There will be daily queries of about 1000000 * 0.7/3 is roughly 240000 queries per day.
4. 240000 queries per day translates to roughly 240000/86400 ~ 3 queries per second, which is a good number, and not too high.
5. QPS for all the pages in the system - View hotel page, View booking/room details page, and make reservation page. If we are assuming that 10% of users reach the next step and 90% of users drop off the flow before reaching the final step. If we backtrack then the view reservation details page QPS = 30, and the view hotel page/details = 300 which are pretty manageable Queries per second.
6. Assuming 5000 hotels have 20 types of rooms, and we want to store 3 years of data , that will be roughly 5000*20*365*3 which is roughly 110000000 ~ 110 million data which is huge, so we need to distribute the data across multiple servers, and hence use sharding.

API design

We will have many REST APIs for the hotel booking system. We will mostly have a microservice architecture for this kind of system.

Hotel Related APIs

1. Get/api/v1/hotels/${id} - Get the details of a hotel
2. POST/api/v1/hotels/${id} - Add a hotel to the system(Internal non user facing)
3. DELETE/api/v1/hotels/${id} - Delete a hotel from the system(Internal non user facing) - Delete a hotel
4. PATCH/api/v1/hotels/${id} - Update hotel information at the system(Internal non user facing)

Room Related APIs

1. Get/api/v1/rooms/${id} - Get the details of a room
2. POST/api/v1/rooms/${id} - Add a room to the hotel (Internal non user facing)
3. DELETE/api/v1/rooms/${id} - Delete a room from the system(Internal non user facing) - Delete a room
4. PATCH/api/v1/rooms/${id} - Update room information at the system(Internal non user facing)

Reservation Related APIs - Mostly all of these are customer facing APIs

1. Get/api/v1/reservations/${id} - Get the details of a reservation
2. POST/api/v1/reservations/${id} - Make a reservation
3. DELETE/api/v1/reservations/${id} - Delete or cancel a reservation.
4. PATCH/api/v1/reservations/${id} - Update reservation details for a customer.

Database design

We will use a Relational Database for the Hotel Booking system.

1. Hotel - hotel_id, name, location, address
2. Customer - customer_id, first_name, last_name, email
3. Reservation - reservation-id, hotel_id, room_type_id, status, totalAmount, customer_id, start_date, end_date
4. Room - room_id, room_type_id, hotel_id, is_available, room_number
5. Room_type_inventory - hotel_id, room_type_id, date, total_inventory, reserved_inventory
6. Rate - rate_id, hotel_id, room_type_id, date, price

High-level design

At a high-level, this system follows a microservice architecture

1. User - a customer makes a booking on their mobile/desktop(this is the client)
2. Load balancers/API Gateway/Rate Limiters - the client request is forwarded to the various services which process the reservation.
3. Hotel Service - this will do all the searching and rendering of hotel related information. There will be the Hotel DB, and hotel db cache in this microservice.
4. Reservation Service - This service will cater to all the reservation related rendering and details. This will have the reservation database. The reservation status can fall into the categories - Pending, complete, rejected, cancelled, refunded depending on the various stages.
5. Payment Service - This service will cater to processing all the payment related information.
6. Rate Service - This will take care of fetching the rates for the rooms being booked for a particular hotel. This will have access to the rate database
7. Hotel Management Service - This is internal to the booking system , and isn't exposed to the customer . All APIs on this service are internal APIs. This will take care of all the admin related tasks like adding a new hotel, adding n ew rooms, updating room or hotel information etc.
8. CDN - Content Delivery Network - This will serve requests to users that are closer to the CDN. This will cache all the static content , images, videos etc for better load time.

Request flows

1. User makes a request to view hotel details, room details.
2. The request passes via the API Gateway to the respective service .
3. if it's a hotel view details page - The hotel service renders that.
4. One the user views the hotel details and selects a room, he's directed to the room details page.
5. The room details are rendered by the Hotels service. The rates for the specific rooms in the hotel, are fetched by the rate service.
6. Once the user decides to make a reservation, they are directed to the final payment page / checkout page where the reservation service initiates the reservation with a status of pending in conjunction with the payment service, also with a pending payment status.
7. The payment service accepts or rejects a payment and based on that, it either completes the reservation or marks it as rejected if the transaction fails. The payment is accordingly marked as either paid or rejected.

Detailed component design

1. Database Queries during reservation - When a user makes a request to reserve x number of rooms, the database is queried fro the room_type_inventory to check if the inventory is available.It's good to have the data replicated, and shard the databases by hotel_id. In order to have efficient and fast lookups, sharding by hash(hotel_id)%number of servers.
2. Caching for the inventory - If the size of the inventory increases, along with sharding for the requess to determine which database shard the request goes to, we can also have a layer of caching for querying if the inventory exists during the booking process. the update in the booking confirmation will be amde both to the database and the cache is also updated. We can introduce a TTL for the cache , say update every hour.

Trade offs/Tech choices

Relational Database Choice -

1. The relationships between entities is pretty structured and clear. Hotels have rooms, rooms have guests(customers) who make reservations.
2. This is mostly a read heavy system, and a less frequent write/update system.
3. We need our transactions to be atomic and consistent. We need to avoid duplicate bookings, duplicate payments, negative balances and so on.

Microservice Architecture

1. There are different types of functionalities involved - For example, managing internal hotel admin tasks, managing payments, handling reservations, fetching rates for different types of rooms, Hotel specific details.
2. There are several entities and a separation of logical functionalities is the best way to handle the chores at different services.

Failure scenarios/bottlenecks

1. The microservices will all be horizontally scalable, by adding instances of the services as required.
2. Relational DB - Horizontally scalable - by using sharding, replicating database - master slave replication across multiple availability zones.
3. In order to avoid concurrency issues, we use reservation_id as the idempotency key in the APIs, so even if there is a double booking, and it's the same key in the reservation request, then it will be ignored due to violating unique constraint.

Future improvements

1. Hotel/Booking recommendations using recommendation engine.
2. Percentage discounts for next booking / customised tour services.