Progressive Search: Showing Flight Results Before All 30 Suppliers Answer
Flight search used to wait on all 30 suppliers before showing anything — one slow responder meant everyone waited. Here's how Server-Sent Events let us stream results the moment each supplier answers.
The Problem
A flight search on our OTA platform fans out to all 30 integrated GDS/NDC suppliers in parallel — but the original design waited for every single one of them to respond, or time out, before showing the user anything at all. Most suppliers answer quickly. It only takes one or two slow ones — a sluggish GDS queue, an occasional timeout — to drag the entire perceived search time up to whatever the slowest responder happened to do that moment. Users stared at a loading spinner for as long as the worst-performing supplier took, even when 28 of the other 30 had already answered in under a second.
The Root Cause
The search endpoint was synchronous and all-or-nothing: results were assembled fully on the server and returned in a single response, only after every supplier settled. Total response time was bounded by the slowest supplier in the batch, not the typical one — a single slow dependency held the entire request hostage, no matter how fast everything else finished.
The Solution
We rebuilt the search response as a stream instead of a single payload, using Server-Sent Events (SSE):
- Suppliers are still queried in parallel exactly as before, but the client opens an SSE connection to the search endpoint instead of waiting for one JSON response.
- As each supplier's response comes back, the server immediately pushes it down the SSE stream as its own event — the client doesn't wait for the other 29 suppliers to catch up.
- The frontend appends and live re-sorts the growing result set as each event arrives, so the user sees real, bookable flights within a second or two, from whichever suppliers happened to answer fastest.
- Slow or timed-out suppliers simply stream in later, or drop off silently if they never respond — they no longer block the first result the user sees.
- The stream closes once every supplier has either answered or timed out, at which point the result set is complete.
The Results
- Time to first visible result is now bound by the fastest supplier instead of the slowest, cutting the wait before a user sees anything real
- Users start scanning and comparing actual flights almost immediately instead of watching a blank loading state for the full round trip
- A single slow or misbehaving supplier can no longer degrade the experience for the entire search — it just arrives late instead of holding everyone else back
Related Case Studies
Jul 23, 2026
How a Redis Stampede (Thundering Herd) Hit Our OTA Search Ranking Engine — And How We Fixed It
When 30 integrated suppliers and 40-50 unique airlines per search met an uncached rank lookup, concurrent cache misses stampeded the database in unison — here's how negative caching and locking around retrieval broke the herd.
Jan 13, 2026
Building an Airline Fare Intelligence Platform Across Multiple GDS & NDC Suppliers
An airline fare intelligence platform integrating multiple GDS and NDC suppliers to aggregate, normalize, and analyze competitor pricing — turning scattered market data into data-driven fare recommendations.
Mar 4, 2025
Cutting ADM Penalties with an Automated Booking Cancellation Service
A background service that automatically cancels un-ticketed bookings before the last ticketing time, saving ~$23K-$27K across 6 OTA clients.