Travel Booking Site with GDS Integration

Project overview

We built a booking engine for a travel agency moving from phone and walk-in sales to online bookings. Travellers search and book flights, hotels or flight-plus-hotel packages; the agency's own agents use the same engine to book for customers and handle changes.

The work covered discovery, UX, a Next.js front end, a Node.js integration layer for the GDS and hotel suppliers, Redis caching, and a staged launch. It belongs to our travel app development practice and complements our travel planner app project.

The client and the challenge

Agents were searching the GDS terminal and several hotel extranets separately, then assembling quotes by hand. Prices changed between quote and payment, and supplier search APIs charged per request and imposed look-to-book limits, so simply putting the GDS behind a website would be slow and expensive. Refunds and schedule changes were handled from notes in a shared mailbox, so agents often did not notice an airline schedule change until the traveller called, and ticketing deadlines were occasionally missed.

The agency wanted fast search, packages priced as one total, honest handling of fare changes before payment, and a back office for ticketing queues, cancellations and refunds.

Solution architecture & delivery

The Node.js layer normalises responses from the GDS and hotel suppliers into one internal model of offers, segments, rooms and fare rules. A search fans out to suppliers in parallel with per-supplier timeouts, so a slow hotel feed returns partial results rather than blocking the page, and results stream into the Next.js interface as they arrive.

Redis caches search results briefly per route, date and passenger mix, which answers repeated and paginated searches without new supplier calls and keeps the look-to-book ratio under control. The cache is only used for browsing: before payment, the selected flight and room are always re-priced live, and if the fare has changed the traveller sees the new price and must confirm it. Cache keys include the point of sale and currency, and entries expire quickly on routes where prices move fast, so a traveller never sees a cached result that belongs to a different market or passenger type.

Packages combine a flight and a hotel into one price using the agency's markup rules, with the component breakdown hidden where supplier terms require it. Booking creates a passenger name record in the GDS and a hotel reservation; if the second step fails, the first is cancelled automatically so travellers are never left with half a package. Ticketing runs from a queue with time-limit alerts for agents.

The back office lets agents search on behalf of customers, apply voids, changes and refunds according to fare rules, and export sales reports. Server-rendered destination and route pages built with our web app development team give search engines crawlable content while prices load client-side.

Key features we built

• Flight search through the GDS with fare rules and baggage details
• Hotel search aggregated from multiple suppliers into one result list
• Dynamic flight-plus-hotel packages with configurable markup
• Short-lived Redis search cache with mandatory live re-pricing before payment
• Automatic rollback when one component of a package fails to book
• Ticketing queue with time-limit alerts for agents
• Voids, changes and refunds handled against fare rules in the back office
• Email and SMS itineraries, reminders and schedule-change notices

How we delivered it

1. Discovery. Reviewing GDS and supplier contracts, API limits and certification steps, and mapping how agents quoted, ticketed and refunded bookings.
2. Integration spike. Proving search, pricing, booking and cancellation against the GDS test environment before building user-facing screens.
3. Build. Two-week sprints on search, packages, checkout and the back office, with contract tests against recorded supplier responses.
4. Certification and soft launch. Completing supplier certification, then opening bookings to agents internally before switching on public checkout.
5. Support. Monitoring supplier errors, adding new hotel feeds and ongoing maintenance, using practices from our high-traffic cloud architecture guide.

Technology choices

• Next.js — server-rendered destination pages for search visibility with a fast client-side search and checkout experience.
• Node.js — non-blocking fan-out to many supplier APIs in parallel, with timeouts and streaming of partial results.
• Redis — a fast short-lived cache for search results and session state that reduces paid supplier calls.

Outcomes

• Travellers book flights, hotels and packages online instead of waiting for an agent's quote
• Agents use one search across the GDS and hotel suppliers rather than several separate screens
• Price changes are shown before payment, so travellers are not charged a stale fare
• Failed package components are rolled back automatically instead of fixed by hand
• Repeated searches are served from cache, keeping supplier usage within contract limits

FAQ