System design interview guide
MakeMyTrip System Design: Flight and Hotel Search
MakeMyTrip sold $10.39 billion of travel in the year to March 2026. That included $5.83 billion of flights. It also included $2.66 billion of hotels and holiday packages, according to its SEC filing. Almost none of this is its own. The seats belong to airlines. The rooms belong to hotels and suppliers. Each has its own systems and its own speed. Their prices change by the minute. Yet a traveller expects a list of options in about a second. And they expect to pay the price they clicked.
MakeMyTrip is an online travel agency. A traveller searches for flights or hotels, compares them, and books. It looks like search plus booking. But the hard part is where the truth lives. Every seat and every room is in an airline or supplier system. Those systems are slow and cost money to ask. Their answers change all the time. Asking all of them for every search would be too slow and too costly. Showing only saved answers would show prices that no longer exist. So the design is a balance. Save answers so search is fast. Refresh the saved answers smartly so they stay mostly right. Then check the live price again at the moment of booking. That is the moment when being wrong really matters. On top of this sits personal content. One example is showing a user the hotels they looked at recently. MakeMyTrip rebuilt this to respond in tens of milliseconds.
Where it shows up
A natural question for travel and marketplace roles. Think of MakeMyTrip, Goibibo, redBus, Cleartrip, Booking.com, Expedia and Agoda. It is also a common general question. Design a flight search engine. Design a hotel booking system. Design any site that sells things it does not own.
Why this question is asked
It tests whether you can design around systems you do not control. Most designs assume your database holds the truth. Here, the truth is in hundreds of outside systems. Every choice trades speed, cost and accuracy. How long can a saved price be trusted? How many suppliers should one search ask? What if the price changes between search and payment? Strong answers keep two paths apart. The read path can be fast and a little wrong. The booking path must be right.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Search flights by origin, destination, dates and passengers, including flights with a change
- Search hotels by city or area, dates and guests, with filters and sorting
- Show prices, availability and fare or room options, and details for one option
- Check the live price again before payment, and tell the user if it changed
- Book: hold the seat or room with the supplier, take payment and confirm
- Handle cancellations and refunds under each airline's or hotel's rules
- Show personal results, such as hotels the user viewed recently
Non-functional requirements
- Search results in about a second, even though the truth is in slow outside systems
- Keep the number of paid or limited supplier calls under control
- The price shown at payment is the price actually charged
- A slow or failing supplier must not slow down the whole search
- Handle holiday and long-weekend peaks, when many people search the same places
- Never charge a customer without a confirmed booking, and match every booking with the supplier
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Yearly travel sales
$10.39 billion (FY26)
This is from MakeMyTrip's SEC filing for the year to 31 March 2026. Travel sales were $10,390.8 million, up 10.4% at fixed exchange rates. This is the value of travel sold, not MakeMyTrip's revenue.
Flights
$5.83 billion (FY26)
Flight sales for the year, the largest part. Flight prices change often. So this is where saved prices go out of date fastest.
Hotels and packages
$2.66 billion (FY26)
Hotel and package sales for the year, up 14.8% at fixed exchange rates. Hotel search is harder to save than it looks. A price depends on dates, number of guests and room mixes.
Searches per booking
many (estimate)
Travellers search, compare and come back several times before booking. Each search can ask many suppliers. This is my estimate: searches outnumber bookings by ten to a hundred times. That is why the read path, not the booking path, drives the cost of the system.
Personal results speed
44 ms typical
In an April 2026 case study with Databricks, MakeMyTrip described its 'recently viewed hotels' feature. Moving it to real-time processing cut the typical delay from about 1.23 seconds to 44 ms. The slowest 1% went from over a minute to about 500 ms.
High-level architecture
Build two paths. The search path is about speed and cost. A search first goes to a store of recent prices and availability. The key is the shape of the search. For flights, it is route and date. For hotels, it is city, dates and guests. Popular searches are almost always answered from this store. For rare searches, or when saved results are too old, the service asks suppliers live. It asks them all at the same time, each with a strict time limit. It returns whatever arrives in time. It does not wait for the slowest supplier. Results are merged, ranked and made personal. Fresh answers are saved for the next search. A background job also refreshes popular routes and cities before users ask. So the busiest searches stay fast and fairly fresh. The booking path is about being right. When the traveller picks an option, the booking service asks that one supplier for the live price. This is called a re-price. If the price changed, the user is told before paying. Then the seat or room is held with the supplier. Payment is taken. The booking is confirmed with the supplier. One booking ID makes every step safe to repeat. Next to both paths runs a real-time personal pipeline. Click events flow through Kafka as they happen. They update each user's data, like the last hotels viewed. The app can read that in milliseconds.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Search service and saved results
It answers most searches from a store of recent prices, keyed by the shape of the search. MakeMyTrip's engineers have written about this. Saving results lets them answer repeated requests in a few milliseconds. When a result is missing, they ask the suppliers and save the answer for next time.
Supplier connections
There is one adapter for each airline, booking system or hotel supplier. Each one turns MakeMyTrip's request into that supplier's format. Each has its own time limit, its own call budget and a circuit breaker. Suppliers differ a lot in speed and reliability.
Refreshing saved results
It refreshes prices for popular routes and cities in the background. So the searches most people make are answered fresh from the store. Less popular searches are refreshed only when someone asks. This keeps supplier costs down.
Hotel availability and room choice
It works out which rooms, or mixes of rooms, fit the dates and guests. MakeMyTrip's engineers wrote that many city searches showed low or zero availability. Part of the cause was real peak-season shortage. Part was rates missing in their own system for that number of guests. That is a data problem, not a supply problem.
Re-price and booking
It checks the live price with the one chosen supplier before payment. It holds the seat or room, takes payment and confirms. This is where saved answers get corrected. The traveller sees the real price before they pay.
Real-time personal results
Click events from the apps flow through Kafka into Spark Real-Time Mode. Each user's last viewed hotels are kept in Aerospike. The results are saved in Redis for the app. MakeMyTrip reported a typical delay of 44 ms. Making it real time raised clicks by 7%.
Payments, refunds and matching
It takes payment and handles cancellations under each supplier's rules. Every day it matches every booking against the supplier's records. So a customer is never charged for a booking the supplier did not confirm.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
search_cachecache_key (route+date+pax or city+dates+guests)resultsfetched_atttlsource_suppliersThe saved answer to one shape of search. Fast-changing prices, like flights close to departure, are kept for less time. Stable ones are kept longer. The fetched_at time lets the system decide when an answer is too old to show.
supplierssupplier_id (PK)type (airline/gds/hotel)timeout_mscall_budgetcircuit_stateOne row per outside source. It holds the limits the connection layer enforces. Budgets matter because many supplier calls are limited or cost money.
offersoffer_id (PK)supplier_idproduct (flight/room)price_minorcurrencyfetched_atOne option you can book, as it was last seen. It is a snapshot, not the truth. The booking path always checks it again with the supplier.
bookingsbooking_id (PK)user_idoffer_idrepriced_amount_minorsupplier_refpayment_idstatecreated_atThe booking. The booking_id is made before any supplier or payment call. It stops every one of those calls from happening twice. The re-checked price is saved, so the customer pays exactly what they agreed to.
user_recent_viewsuser_idlast_n_hotelsupdated_atEach user's data for personal results. It lives in a fast key-value store and is updated from clicks within milliseconds. It is small per user but huge in total. Nearly every app screen reads it.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Saved prices go out of date
The main problem is that a saved price is a guess. Flight prices can change several times a day. A hotel's last room can sell at any moment. If you save prices for too short a time, every search hits slow, costly suppliers. If you save them too long, travellers see prices that no longer exist. Then they feel cheated at checkout. The answer is to trust different things for different times. Flights close to departure and popular dates get shorter times. Stable options get longer times. Popular searches are refreshed in the background, so they are fast and fresh. Most important, never trust the saved price for the booking itself. The saved price can be wrong because the re-price step exists.
Checking the price again at booking
Between search and payment, the price can change. So before taking money, the booking service asks the chosen supplier for the live price. If the price is the same, booking goes on. If it went up, the traveller sees the new price and is asked to confirm. If the option is gone, they go back to the results. It is a small step. But it is what makes heavy saving safe. All the correctness of the system sits in one live call per booking. It is not spread across millions of searches.
Asking many suppliers without waiting for the slowest
A search that asks several suppliers live is only as fast as the slowest one. Unless you stop waiting. So the calls go out at the same time, each with its own time limit. When the time for the search runs out, the service returns what it has. Late answers are saved for the next search. A supplier that keeps timing out trips its circuit breaker. It is skipped for a while. So its trouble does not slow every search. The trade is completeness for speed. Now and then a result from a slow supplier is missing. That is better than every traveller waiting for it.
No hotel rooms can be a data problem
It is easy to assume that 'no rooms available' means the city is full. MakeMyTrip's engineers wrote that many city searches showed low or zero availability. Some of it was real peak-season shortage. But some of it was rates missing in MakeMyTrip's own system for that number of guests. For example, no rate was loaded for three adults in a room that could hold them. The lesson is to measure where 'no results' comes from. Part of the fix is better data from suppliers. Part is smarter room choice. For example, offer two rooms that together fit a group, when no single room has a rate for that group.
Personal results in milliseconds
Showing a traveller the hotels they viewed a minute ago helps only while they are still browsing. MakeMyTrip described this in an April 2026 case study with Databricks. Its 'recently viewed' feature ran in small batches. It had a delay of one to two seconds. The slowest 1% took over a minute. It moved to Spark Real-Time Mode, reading clicks from Kafka. It kept each user's last viewed hotels in Aerospike. And it served them from a Redis cache. The typical delay dropped to 44 ms. The slowest 1% dropped to about 500 ms. Clicks rose 7%. In an interview, the point is that this store is separate from search. It is small per user, always updating, and read with one key lookup.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Answer search from saved results versus asking suppliers live
Asking live gives the freshest answer. But it is slow, often limited and sometimes paid per call. It also multiplies with every search. Saved results are fast and cheap, but they can be out of date. Using saved results for search and a live re-price for booking gets most of both.
Wait for every supplier versus return what arrives in time
Waiting for all suppliers gives the most complete results. But then every search is as slow as the slowest supplier. Returning what arrives within a time limit keeps search fast. Sometimes one option is missing. It can still appear on the next search, from the saved results.
Refresh popular searches early versus only when asked
Refreshing everything early would keep every price fresh. But it would call suppliers for searches nobody makes. Refreshing only popular routes and cities keeps the busiest searches fresh. Rare searches are refreshed when someone asks.
Tell the user about a price change versus absorbing it
Absorbing small price rises feels smoother. But it costs money on every old price and hides a real problem. Showing the new price before payment is honest. It stops saved-price mistakes from becoming losses. The cost is that some travellers leave at that step.
Real-time processing versus small batches for personal results
Small batches are simpler to run. But they added one to two seconds of delay. That is too slow to help in the same browsing session. Real-time processing cut the typical delay to 44 ms and raised clicks by 7%. The cost is running a streaming system that must stay up all the time.
How MakeMyTrip actually does it
The business numbers come from MakeMyTrip's SEC filings for the year to March 2026. The personal results pipeline and its numbers come from an April 2026 Databricks case study, written with MakeMyTrip engineers. The notes on saved results and on hotel availability come from MakeMyTrip's own engineering posts on Medium. We could not read those posts in full. So we use only what their published summaries say. MakeMyTrip has not published the full design of its flight and hotel search. So the rest of the design is a standard one that fits these facts. Estimates are marked as mine.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Cache-Aside Pattern
foundation / caching strategies
Search Engines
intermediate / database types storage
Circuit Breaker
advanced / reliability resilience
Timeout Patterns
advanced / reliability resilience
Idempotency Keys
intermediate / api design protocols
Message Queues
intermediate / messaging event systems
Saga Pattern
advanced / distributed systems core
Related system design interview questions
Practice these next. They lean on the same core building blocks as MakeMyTrip.