MakeMyTrip sold $10.39 billion of travel in the year to March 2026, according to its SEC filing. That was $5.83 billion of flights, and $2.66 billion of hotels and holiday packages. Almost none of it is its own. The seats belong to airlines. The rooms belong to hotels and suppliers. Each of them has its own systems and its own speed. Their prices change by the minute.
Yet you expect a list of flights in about a second. And you expect the price you clicked to be the price you pay. Those two wishes pull in opposite directions. The way an online travel agency handles that is one of the most useful patterns in system design. It works for any site that sells what it does not own.
Why you cannot just ask everyone
Here is the obvious design. When someone searches, ask every airline and hotel supplier for live prices. Merge the answers and show them. It is correct, and it does not work.
Supplier calls are slow. Many have rate limits, and some cost money per call. Travellers search, compare and come back several times before they book. So searches outnumber bookings by ten to a hundred times. That is my estimate, but anyone who has planned a trip knows it is true. Ask live for every search, and the system is slow and costly. It is also only as fast as the slowest supplier.
Cache the read, check again at the write
The answer is to split the system into two paths. Each path is allowed to be wrong in a different way.
The search path is about speed and cost. It answers from a cache of recent prices and free seats or rooms. The cache key is the shape of the search. For flights, it is route and date. For hotels, it is city, dates and guests. MakeMyTrip's engineers have written about this. With caching, they answer repeated searches from different users in a few milliseconds. On a cache miss, the system asks the suppliers and saves the answer for next time. Popular routes and cities are refreshed in the background, before anyone asks. So the searches most people make are fast and fairly fresh.
The booking path is about being right. A traveller picks an option. The booking service asks that one supplier for the live price and whether it is still free. This is called a re-price. If the price is the same, booking goes on. If it went up, the traveller sees the new price before paying. If the option is gone, they go back to the results.
This is the whole trick. All the checking happens in one live call per booking. It is not spread across millions of searches. The cache is allowed to be wrong only because the re-price step exists.
Do not wait for the slowest supplier
Sometimes a search does have to ask suppliers live. Then it asks them all at the same time, each with its own time limit. When the search runs out of time, it returns what it has. Late answers are saved in the cache for the next search. Say a supplier keeps timing out. It trips a circuit breaker and is skipped for a while. So its bad day does not become everyone's bad day.
The trade is completeness for speed. Now and then, one option from a slow supplier is missing. That is far better than every traveller waiting for it.
"No rooms available" can be a data bug
This is my favourite detail. It comes from MakeMyTrip's own engineering writing. They found that many city searches showed few or zero hotels on the listing pages. The reasons were not only real shortages in peak season. Some of it was missing rates in their own stock system, for the number of guests asked for. For example, there was no rate loaded for three adults in a room that could hold them.
I would bring that lesson to any search system. Find out where "no results" comes from before you assume the world ran out. Part of the fix is better data from suppliers. Part is smarter room choice. Say no single room has a rate for that many guests. Then offer two rooms that fit the group together.
Personal results in 44 milliseconds
The last piece sits beside search. It shows you the hotels you looked at a minute ago, while you are still browsing. MakeMyTrip described this in an April 2026 case study with Databricks. The pipeline used to run in small batches, with one to two seconds of delay. The slowest 1% took over a minute.
They moved it to Spark Real-Time Mode, reading clicks from Kafka. They kept each user's recently viewed hotels in Aerospike, and served them from Redis. The typical delay dropped from about 1.23 seconds to 44 milliseconds. The slowest 1% dropped to about 500 milliseconds. Clicks rose 7%.
The design lesson: this personal store is separate from the search path. It is small per user, always updating, and read with one key lookup.
What I would say in an interview
- Split a fast, cached search path from an exact booking path.
- Key the cache by the shape of the search. Refresh popular searches ahead of time. Give fast-changing stock shorter cache times.
- Ask suppliers at the same time, with time limits and circuit breakers. Return what arrives in time.
- Re-price with the one chosen supplier before taking money, and show any change.
- Use a booking ID as the idempotency key for the supplier and payment calls.
MakeMyTrip has not published the full design of its flight and hotel search. So parts of this are a standard design for this kind of site, built to fit its published facts. The full version, with the data model, trade-offs and every source, is in the MakeMyTrip system design walkthrough. The same problem of selling stock you do not own shows up at Airbnb. And redBus, which MakeMyTrip also owns, adds the seat-holding side of it in the redBus design.
Top comments (0)