How surge pricing works during online hotel booking

Many of us would have faced this situation, while we plan a vacation(In my case, this generally takes a week)and try to book a room on online platform, the price of the room has already changed from the price that we had seen when we started planning, This gives a major setback to your plan if the price has increased. This has potential to even cancel your plan if by any chance you are planning to travel by air(These people are the masters in surging the price high, even if you search multiple times)

Being a software engineer, I always thought to deep dive on the design of this feature but I was too lazy to start until I got a push from few friends in our small community of Software System Design .

I don’t have much idea on the parameters that dictates the dynamic/surge pricing in the real world. So, I have come up with my own easy requirements/parameters and tried to solve the problem.

Requirement

Design a feature that is capable to automatically surge the booking price of the room in a hotel based on below criteria.

1. There is no surge until 50% of the room is booked in the hotel, after that per room being booked will add 5% of the last booked price for the hotel
2. In a different season there will be added percentage on top of the normal surge price that is configured by the hotel owner

For simplicity purposes it is assumed that each room is of the same type so that base price, etc remains to be the same.

Design Approach

Before we move into the details of API and DB design first let’s discuss the non-functional requirements and other details

1. Let’s assume we are developing it for company like OYO which is one of the largest hotel owner is India, with 15K hotels comprising for around 300K rooms
2. Search data can be cached and the price to be shown during the room search may not be updated and can be asynchronously updated.
3. There will be approximately 10x detailed views of the hotels with respect to number of bookings.

Before we move ahead further let’s also discuss and determine the kind of data and network traffic that we may have to face per day.

We know that the dynamic pricing per day is requirement #1. #2 is the static with respect to #1.

Let’s do certain level of mathematics

1. Since each hotel has the same type of room, we can afford to maintain the price at hotel level, If that was not the case we would have to maintain it at individual room level. So price to be updated for the same hotel multiple times(50% of the number of rooms in the hotel) .In the worst case 150K times update to 15K hotels, now 150K updates/day of the room price is not huge as we can see the number of updates are ~2 updates/sec.
2. After the initial search, we would need to show the details of the hotel when the user selects the particular hotel for the booking and review the details, At this point we would need to show the actual price and this call can go to the pricing engine service
   Number of view request(max) = 300K * 10 = 3 Million/day ~35 req/sec
3. Let’s look at the data growth per day, 300K room bookings per day
   a. Assuming each booking has 20 data fields(columns) to save, It can have at max 20 * 32 Bytes(Average per field data size) = 640 Bytes.
   b. Total data size per day = 300K * 640Bytes = 200 MB data.
   c. Per month growth is 200 MB * 30 = 6 GB data.
   d. So does this amount of data concerns us, No because we can maintain the price per hotel level, 15K that will correspond to 15K * 640 Bytes = 10 MB data/day.
   e. So if we maintain the price of room at hotel(since all rooms are same type) per day data growth is 10MB which we will be able to maintain quite comfortably.
   f. Since the requirement #2 is per season we can just afford to maintain the data for each hotel and update the same when the season changes. For historical data we can maintain the trail in some other data table/store

So from the data and traffic growth perspective, application is light weight with the given requirement. Now, Let’s move on to API and DB design

API design

Now, Let’s see the API that would be needed.

1. GET room price (To get the price of the room in the hotel where the booking starts at day X.)
   a. params can be HotelID, RequestID, Start Date.
2. UPDATE room price (To update the price of the room of the hotel when the booking is done for the same hotel, which will also take care of updating the cache asynchronously.)
   a. params can be HotelID, RequestID, Start Date, End Date, incrementPercent
3. CREATE seasonal price structure for hotels(To support the requirement #2 to update the percent of increment on top of the current price that would be evaluated.)
   a. params can be HotelID, RequestID, Start Date, End Date, incrementPercent

DB Schema Design

We have seen that data growth is not huge, Also the requirement is relational and booking data is required hence ACID properties can also be thought around as the important requirement so we can go with SQL like MySQL or PostgresSQL. If we need to use the service in other countries we can have country level sharding. Also country level app deployment can be a way to go if we would need to maintain the edge servers in different region of our operations

Tables and Schema as per the requirement of the problem

• hotel(ID, location_lat, location_long, name, number_of_rooms, owner_id, created_at, updated_at)
• hotel_level_price(ID, hotel_id, price_date, base_price, last_price, current_price, vacant_room_count, created_at, updated_at)
• seasonal_charges(ID, hotel_id, start_date, end_date, seasonal_charge_percent, created_at, updated_at)

High Level Architecture Design

Few major services that would be required to demonstrate the surge pricing functionality would be namely Search service, Booking service, Pricing Engine(Our area of focus where the surge price would be calculated)

Very High Level architecture diagram of online hotel system that can demonstrate surge pricing functionality

Let’s see the sequence flow diagram, which will give us the clear understanding of how the various components in the above architecture are interacting.

Sequence Flow Diagram to show the interaction between various components that happen while booking a hotel

I have purposefully removed the Web/Mobile client for simplicity and better clarity.
Only the happy path is considered for the simplicity of the UML
Few major steps like redirecting user to payment section, etc are purposefully skipped to keep focus on the surge price calculation requirement

Let’s look at the sequence flow in details

1. User search for the hotels in the home page and search engine will respond with many hotels to the user
2. User select the hotel to review, search engine gets the actual price of the hotel from pricing (this is where the surge price calculation comes into the picture)and send the response to user
3. User request the booking, booking engine gets the price from the pricing engine and show it to user for the confirmation of the booking
4. User confirms “book” and booking engine books and requests the pricing engine to update the price for the next booking(this can also happen asynchronously) and respond to the user with booking data.

Price Engine Implementation

If we see the way the price is calculated
1. We see that for the first 50% booking of the hotel rooms the base price is the price that is considered
2. After which there is a surge for each room being booked,
3. Also there is a seasonal charge on top of the price that is calculated.

I can think of Decorator pattern as the suitable design pattern to calculate the price of the hotel room. So the initial price being the base price will be decorated with surge charge(which can be calculated based on the number of rooms being booked just before the current booking), which again is decorated with seasonal charges.
This design pattern gives us the flexibility to include any other charges like GST or different kind of surge price to add dynamically without much change in the code bases.

Let’s Look at the UML class Diagram after which we will discuss each class in details.

UML Class Diagram for the price engine

1. Controller class : It is responsible for interacting with the other services, It takes the request from the API layer and calls all the price decorators one after the other to calculate the net price of the room.
2. BasePrice class : It is responsible for querying the base price of the hotel from DB for current day. It also maintains other data that might be needed by other classes. It holds the data so that other classes do not have to query the data again.
3. SurgePriceDecorator class : It is responsible for checking if the current booking is above 50%, If it above 50% then instead of base price, 5% on top of last price is considered as the price for the room
4. SeasonalPriceDecorator class: It is responsible for adding the seasonal price charges which will be on top of the surge price calculated in the last step.

Conclusion

This is the very simple use case of price surge parameters based on which the system is designed. This design is just to give the readers a clarity on how we can design such a system. In reality price surge would be dependent on many factors like number of search requests, location, weather conditions and many other factors.

Thanks so much guys for patiently reading it. Do clap if you liked it.