Multi-Supplier Travel Aggregation: Architecture for Combining Flights, Hotels, and Ground Transport

TL;DR: India's online travel market is growing at roughly 13% annually — nearly double the global average — and is projected to reach ₹3,835 billion by FY28. But building a platform that actually aggregates flights, hotels, and ground transport across GDS, NDC, and direct supplier APIs is a genuinely hard architecture problem, not a matter of stitching together a few REST calls. This article covers what a multi-supplier travel aggregation architecture needs to get right: data normalization, real-time pricing under API cost pressure, and the GDS/NDC dual-integration reality most platforms end up needing.

Why India's travel market makes this architecture decision urgent

The scale of opportunity is real. India's online travel market was valued at roughly $23-25 billion in 2025-2026 depending on methodology, with the broader OTA segment projected to reach ₹3,835 billion by FY28 — a 13% compound annual growth rate that significantly outpaces the roughly 6% global average. Mobile dominates at nearly 80% of bookings, driven by India's mobile-first internet adoption and UPI-based checkout convenience.

For any platform — a new OTA, a corporate travel management tool, a niche vertical aggregator — trying to capture a share of that growth, the technical foundation is the same regardless of the specific product: reliably combining inventory from multiple, structurally different supplier sources into a single, fast, accurate search and booking experience. Getting that foundation wrong doesn't just mean a slower product; it means showing customers stale prices, failing bookings after a customer has committed, and burning through supplier API budgets on searches that never convert.

The core architectural challenge: suppliers don't agree on anything

The fundamental difficulty in multi-supplier travel aggregation is that no two supplier sources structure their data the same way, and reconciling that is harder than it sounds from the outside.

GDS systems (Amadeus, Sabre, Travelport) provide broad, standardized-ish access to airline inventory built up over decades, with well-established but relatively rigid data models. NDC (New Distribution Capability) connections access airline offer and order management systems more directly, exposing richer fare bundles and ancillaries, often with better net pricing — but NDC schemas are still maturing and vary meaningfully airline by airline, with less standardization than GDS. Then there are bedbanks and hotel wholesalers, direct supplier APIs for airlines and hotel chains that bypass GDS/NDC entirely, and ground transport providers with their own, entirely separate API conventions.

A platform trying to show a customer one unified search result across all of this needs to normalize fares, baggage allowances, seat selection rules, cancellation policies, markups, commissions, and currencies into a single internal data structure — while still preserving enough supplier-specific detail to actually complete a booking, since ticketing and after-sales service (changes, cancellations, refunds) require the original supplier-specific rules, not just the normalized display version. Building this normalization layer well, so it degrades gracefully rather than breaking when a supplier changes its response format, is most of the real engineering difficulty in this category.

A concrete example of the standardization problem: one tour or activity supplier might structure a single product with 15 variant options (different departure times, group sizes, add-ons), while another only offers fixed-departure, no-variant products. A naive aggregation layer that assumes one structure breaks silently on the other — either dropping valid options or crashing on unexpected data shapes.

The GDS-vs-NDC decision most platforms don't actually get to make

A common early architecture question is "should we build on GDS or NDC?" — but for most platforms with real ambitions, the honest answer is both, in parallel, because each covers gaps the other doesn't. GDS remains the broadest, most standardized way to access airline inventory across carriers; NDC provides richer content and often better net pricing from carriers that have invested in it, but with inconsistent schemas and narrower per-airline coverage. Most travel startups end up either integrating a supplier that abstracts this complexity on their behalf, or building and maintaining both a GDS connection and an NDC aggregator connection in parallel — which is real, ongoing integration work, not a one-time decision.

Building a single major GDS or NDC integration from scratch typically takes two to six months of dedicated development time, and that's for one supplier connection — a platform genuinely aggregating multiple suppliers across flights, hotels, and ground transport is looking at a meaningfully larger integration surface, which is exactly why the architecture decisions below (abstraction layers, normalization) matter as much as they do.

Architecture patterns that actually hold up under real traffic

1. Microservices separation by workload characteristics, not just by domain. Search, pricing, booking, and payment have fundamentally different performance and reliability requirements — search is the highest-volume, burstiest workload and can tolerate eventual consistency and aggressive caching, while booking and payment need strict consistency and can't be cached at all. Isolating these into independently scalable services means a traffic spike in search (a viral fare sale, a holiday booking rush) doesn't degrade the reliability of the booking and payment paths that are actually completing revenue-generating transactions.

2. Route-aware caching, not a single blanket cache policy. Different API routes need fundamentally different caching rules — a flight search result might be cacheable for seconds given price volatility, while static content (airport codes, hotel amenity data) can be cached for hours or days. Centralizing caching rule configuration by route, rather than duplicating ad hoc caching logic inside each microservice, keeps the strategy consistent and makes it possible to actually reason about staleness risk across the platform.

3. A supplier abstraction layer that isolates the rest of the platform from individual supplier quirks. Supplier APIs change — fields get deprecated, new mandatory parameters appear, NDC schemas evolve as airlines mature their implementations. An integration that isn't actively maintained against this drift accumulates silent failures: fields that quietly stop populating, deprecated parameters still being sent, new required fields going unfilled. A well-designed abstraction layer contains this churn to the supplier-specific adapter code, rather than letting supplier API changes ripple into search, pricing, and booking logic across the platform.

4. Explicit reprice-before-booking logic. Because fares and rates can change between when a customer sees a search result and when they complete a booking — sometimes within seconds for volatile fare classes — the booking flow needs an explicit reprice step immediately before payment confirmation, with clear customer-facing handling when the reprice differs from the originally displayed price. Skipping this step to simplify the booking flow is a common shortcut that produces failed bookings, chargebacks, and customer trust problems.

5. Cost-aware API call budgeting. Live supplier API calls, particularly to GDS systems, typically carry real per-call costs, which creates direct tension with wanting fresh, real-time pricing on every search. Platforms that don't architect around this — calling every connected supplier live on every search regardless of likely conversion — burn through API budgets on searches that were never going to convert. Smarter approaches use cached or slightly-stale results for initial search display, with live repricing reserved for the point closer to actual booking intent.

A reference architecture at a glance

Handling failures gracefully: the part most platforms skip

Beyond the happy-path architecture, a genuinely reliable multi-supplier platform needs explicit failure handling for the scenarios that happen routinely in production, even if they're rare in any single search or booking:

Partial supplier failures during search. If one of five connected hotel suppliers times out or returns an error during a search, the platform shouldn't fail the entire search — it should return results from the suppliers that did respond, ideally with a way to backfill the failed supplier's results asynchronously if the customer stays on the results page. A search architecture that treats "all suppliers must respond" as a hard requirement will show customers empty or failed searches far more often than necessary, directly hurting conversion.

Booking failures after payment authorization. In rare but real cases, a supplier's booking confirmation can fail after payment has already been authorized — inventory sold out between reprice and booking confirmation, a supplier-side system error, a network timeout during the booking call whose actual outcome is unknown. Platforms need an explicit reconciliation process for this state: does the booking actually exist on the supplier's side even though the confirmation response failed? Getting this wrong either leaves a customer charged with no booking, or creates a booking the platform doesn't know it made and can't service.

Idempotency in booking retry logic. When a booking API call times out without a clear success or failure response, naive retry logic risks creating a duplicate booking if the original call actually succeeded on the supplier's side. Idempotency keys — a unique identifier attached to each booking attempt that suppliers (or the platform's own retry logic) can use to recognize and deduplicate a repeated request — are essential infrastructure for this, not an edge-case afterthought.

Graceful degradation under supplier rate limiting. Most supplier APIs enforce rate limits, and a platform experiencing a traffic spike (a sale, a viral moment) can hit these limits precisely when demand — and the cost of a failed search — is highest. Architecture needs a defined fallback (serving cached results, queuing requests, prioritizing booking-intent traffic over casual browsing) rather than simply returning errors when a rate limit is hit.

Building this failure handling explicitly, rather than assuming the happy path is the only path that matters, is a meaningful part of what separates a demo-quality aggregation platform from one that holds up under real transaction volume and real supplier unreliability.

Conclusion: The architecture is the product

In travel aggregation, the supplier integration and normalization architecture isn't a backend implementation detail — it directly determines whether customers see accurate prices, whether bookings actually complete, and whether the platform can scale into India's rapidly growing online travel market without buckling under real-time load and API cost pressure. Syslabs works with travel platforms and OTAs to design and build multi-supplier aggregation architecture — GDS and NDC integration, normalization layers, and caching strategy — built to handle real supplier volatility and scale from day one.

Sources

• PHPTravels, "NDC vs GDS Explained: The Powerful 2026 Guide to Airline Distribution"
• AltexSoft, "Travel Search Caching: How OTAs Scale to Millions of Users"
• Zentrumhub, "Travel API Integration: Types, Pricing, Benefits & Timeline" (2026)
• Mordor Intelligence, India Online Travel Market Size & Growth Forecast (2025-2031)
• NewKerala/industry coverage, India OTA Market projections to FY28