System design for Hotel booking apps — II

System design for Hotel booking apps — I This will be a 2 part series in which we will go through how a hotel booking app is designed with the help of HLD/LLD…

Search Fragment

1. We will have a separate fragment/container view which only serves purpose of searching the place the user wants to book hotel from.(Refer to screens discussed in 1st part)
2. This removes the call for hotels api calls repeatedly (You can see the same from major apps when searching , they don't give whole info about the hotel/item you want . They want a description about it )
3. When user clicks on the location they find after entering their query , then we shall move them to separate hotel/room list view .
4. On the fragment we will go with some approaches :- i. We show user trending searches around their location to keep them more engaged . ii. We will approach this in a debounce search manner rather than insta searching it . iii. When user selects a search item , we cache it locally and for
5. In the First approach , we will show a list of trending places which gets refreshed depending on the config from backend side . This makes the app more interactive and easy to use from them .
6. For the 2nd part , we have a gap of 200–300 ms after user finishes typing then we make the API call (contract in the image) . This removes redundant api calls as user type typically fast .
7. We should also store the recent searches made by user in a cahce with TTL/LRU policy.

Search Response Fragment

1. One thing you will notice is that we are using same api contract , same response and even same view from app home screen . This allows us to have central theme throughout our app and consistency .
2. The api modelling and response is same as we did in our dashboard screen .
3. One thing we should consider that the filters and sorts that we provide should be dynamic and change depending on user search type .
4. This helps handling different countries with different setups and remote config also don't require app release as well .

Hotel/Room Detail Screen

1. Now when user clicks on the overview from either search/dashboard , we make the API call against that entity ID .
2. This screen will contain everything about the place where user clicked like reviews , room costs , ammenties etc .We can also near by locations by using simillar model classes .
3. This page will be mostly view only , dedicated only for user go through everything about the place .

Bonus : Booking a Room

This a bonus section on how to design when a user is going to book a room in the hotel

1. This parts starts when user is going to make a purchase for that room and will cover financial handling in mobile.
2. When finalises the date and details about their stay and wants to proceed with the transaction , we will temporary mark that room as booked for window of time .
3. this time is handled shared from backend , we should not handle the time locally as user can change their time settings and mess up with our windows .
4. we can use webhook or directly get a counter from api response when making the transaction .
5. This approach ensures that every available gets a chance within same window and complete the transaction .
6. Every details should be handled on backend side even total price , coupons , currency to support reactive programming .
7. Each transaction will have 3 states/enums depending on their state of purchase .

Summary

In the end we want through many architectures and concepts on mobile side , showing how to handle user searching , booking and trands on a larger scale .

Thank you so much for reading and supporting me , please let me know if i missed something or a mistake on my side .

Connect with me :-

Twitter Linkedin