How to Make an App Like Expedia

Building a travel aggregator is one of the more architecturally complex things you can take on. The data volumes are large, the third-party integrations are unreliable, and pricing logic changes faster than most teams expect. This post walks through what actually goes into building something at Expedia's level — the systems, the trade-offs, and where teams typically underestimate the effort.

What Does an App Like Expedia Actually Do, Technically?

Expedia is not a travel agent. It is a real-time aggregation and transactional platform that queries hundreds of suppliers simultaneously, normalises wildly inconsistent data, and completes bookings in seconds. The public-facing search is the easy part.

Under the hood, the core functions are:

• Flight, hotel, and car inventory aggregation from GDS providers (Amadeus, Sabre, Travelport) and direct supplier APIs
• Real-time pricing with fare rule application
• Session-based cart management across multiple booking types
• Payment orchestration with fraud scoring
• Post-booking fulfilment: PNR creation, e-ticket issuance, voucher generation

Each of these is a system in its own right. Most teams scope the search UI and forget the fulfilment layer until it breaks in production.

GDS vs Direct Supplier APIs

The choice between GDS and direct supplier connectivity matters early. GDS access (typically via NDC or EDIFACT) gives you broad coverage but adds latency (200–800ms per query is typical) and licensing cost. Direct APIs from airlines like IndiGo or Emirates are faster and cheaper per transaction but require separate commercial agreements with each supplier.

Most serious aggregators use both: GDS for long-tail inventory, direct APIs for high-volume routes where the unit economics justify the integration work.

The Caching Problem

You cannot hit live supplier APIs on every search. The math does not work. A single hotel search in a metro city might fan out to 40+ suppliers. At scale, that is thousands of outbound HTTP calls per second.

The standard approach is a two-layer cache: a warm cache populated by background crawlers (updated every 15–30 minutes), and a live-price confirmation call triggered only when a user selects a specific result. Redis with a TTL of 20–30 minutes covers most of the warm layer. The confirmation call uses the supplier's live pricing endpoint, which is where most booking failures happen.

What Tech Stack Should You Build On?

There is no single right answer, but there are wrong ones. A monolithic Rails or Django app will not survive the fan-out search pattern at any meaningful scale. The search layer needs to be independently deployable and horizontally scalable.

A typical stack for a mid-scale aggregator:

Layer	Common Choice	Notes
Search API	Go or Java (Spring Boot)	Low latency, high concurrency
Aggregation workers	Kafka + Go consumers	Fan-out and result merging
Booking service	Node.js or Python (FastAPI)	Business logic, state machines
Database	PostgreSQL + Redis	Relational for bookings, cache for search
Frontend	React + Next.js	SSR matters for SEO on listing pages
Mobile	Flutter or React Native	Single codebase if budget is a constraint

The aggregation layer is where most teams get architecture wrong. Synchronous fan-out with a timeout (typically 3–5 seconds) works at low scale. Beyond a few hundred concurrent searches, you need async fan-out via a message queue, result merging, and partial result streaming back to the client.

How Do You Handle Payments and Compliance?

Travel payments are messier than e-commerce. You are often collecting money in one currency, paying a supplier in another, with a markup baked into the middle. The merchant of record question matters: if you are the MOR, you own chargebacks and refund liability.

Payment gateway options worth considering: Stripe (strong API, not ideal for high-risk travel merchants in some regions), Razorpay (if India is your primary market), or Adyen (better for multi-currency and international). For fraud scoring, most teams at this scale use a combination of Stripe Radar rules and a third-party layer like Kount or Signifyd.

PCI-DSS compliance is non-negotiable if you are storing or transmitting card data. The practical path is to not store card data at all: use a tokenisation approach where the gateway handles card capture via an iframe or hosted fields, and you only ever see a token. This drops your PCI scope significantly.

GDPR and India's DPDP Act both apply if you are collecting passenger data. PII must be encrypted at rest (AES-256 is the current standard), and you need a clear data retention policy — most travel platforms keep booking data for 7 years for tax purposes, but strip PII from cancelled or incomplete bookings much sooner.

Building the Search Experience Without Killing Your API Budget

The UX of a travel search looks simple. The implementation is not.

Autocomplete on the search field alone requires a geo-database. IATA airport codes, city names, and hotel names need fuzzy matching. Algolia works for this at smaller scale; at larger scale, a custom Elasticsearch index gives you more control over the ranking logic.

Filters — price range, star rating, amenities — need to work on cached results, not live data. This means your cached result objects must carry enough metadata for client-side or server-side filtering without re-querying suppliers.

Sorting by price is straightforward. Sorting by "value" or "recommended" requires a ranking model. Expedia uses machine learning for this. At earlier stages, a rules-based scorer (price per night × location score × review score) gets you far enough.

Map-based search adds another layer. You need a tile server and geospatial indexing. PostGIS on top of PostgreSQL handles proximity queries well. For the map UI, Mapbox or Google Maps Platform both work; Mapbox is cheaper at scale.

What Does It Cost and How Long Does It Take?

A useful way to think about this: Expedia's engineering team is in the thousands. You are not building Expedia. You are building something that covers the core booking loop for a specific market or vertical.

A focused MVP covering one travel category (say, hotels only) with two or three supplier integrations, basic search and filters, payment, and booking confirmation takes 6–9 months with a team of 8–12 engineers. That assumes the team has prior experience with GDS or supplier API integrations.

Scope creep in this domain is almost always driven by supplier inconsistencies. One airline's API returns prices including taxes; another does not. One hotel supplier sends availability in UTC; another sends local time with no timezone indicator. Budget at least 30% of your backend integration time for data normalisation.

Cloud infrastructure cost at MVP scale (a few thousand searches per day) runs to roughly $2,000–$5,000/month on AWS or GCP, dominated by compute for the aggregation workers and data transfer costs from supplier API calls.

Conclusion

The core booking loop is buildable. The hard parts are supplier integration breadth, data normalisation, and the edge cases in the fulfilment layer that only surface after real bookings fail.

If you are evaluating build vs. buy, the honest answer is that buying a white-label solution (Amadeus Travel Platform, Travelgate.X) makes sense if your differentiation is not in the technology. If the product is the differentiation, you build it. The shelf cost of a white-label is lower upfront; the ceiling on what you can do with it is much lower too.

Start with one supplier, one booking category, and real users before scaling the integration surface. The architecture above will hold. The unknowns are in the supplier data.

If you want to talk through how a specific part of this architecture applies to your situation, reach out to the Sodio team directly.

FAQ

How long does it take to integrate with a GDS like Amadeus or Sabre? A basic flight search and booking integration with Amadeus NDC or Sabre's REST APIs takes 8–14 weeks for an experienced team, assuming you already have a sandbox account and commercial agreement in place. The EDIFACT-based legacy APIs take longer; plan for 16–20 weeks if you are working with older interfaces.

Do you need a travel agent licence to build a booking platform? In most jurisdictions, yes, or you need to operate under one. In India, IATA accreditation is required to issue tickets directly. Many platforms operate under an accredited consolidator's licence initially, which is faster to set up. Legal requirements vary significantly by country; get local legal advice before you start integration work.

What is the biggest technical mistake teams make when building travel apps? Underestimating supplier data inconsistency. Teams design a clean data model based on the first API they integrate, then spend months patching it as every subsequent supplier sends data in a different format. Build a normalisation layer from day one, and treat each supplier's data as untrusted input that needs validation.

Can a small team realistically build this without GDS access? Yes, for specific niches. If you focus on direct hotel bookings, you can integrate with hotel chain APIs (Marriott, Hilton, IHG all have developer programmes) and aggregators like Hotelbeds without GDS access. Flight aggregation without a GDS is harder; you are limited to airlines with public NDC APIs, which covers major carriers but not full global inventory.

How do you handle booking failures and refunds at scale? With a state machine on every booking record. Each booking moves through states: initiated, payment captured, supplier confirmed, tickets issued, fulfilled. Failures at each state need a different recovery path. Refund logic should be a separate service, not embedded in the booking flow. Most platforms process refunds via the original payment method within 5–10 business days, but supplier refund timelines (which can be 30–45 days for some airlines) create a cash flow gap you need to account for.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.