Guru — flight search orchestration

01 — The problem

Finding the right business-class fare for a client means checking three different worlds: market prices, award availability across airline programs, and card-program inventory. Each lives in its own system, each answers slowly, and the answer changes by route, date, and cabin. A concierge handling one request could burn most of an hour tab-hopping — and still not know whether the award seat beat the cash fare.

Guru turns that hour into a queued search: describe the trip in plain language or a form, and every provider gets swept in parallel while the team works on something else.

02 — Constraints

• Flight-data providers are hostile to automation. Some award inventory isn't exposed through any API and only exists inside a rendered page.
• Searches are long-running by nature — minutes, not milliseconds — so the system had to be a queue with resume, retry, and post-run review, not a request/response app.
• The right search strategy differs by region and trip shape; the search model is an explicit numbered plan per route direction, not a single generic query.
• It's an internal tool running on client work, so screenshots here are sanitized and there's no public demo.

03 — The approach

A strategy engine expands each trip request into numbered search plans, runners execute them against Amadeus and ITA Matrix alongside award sources, and results stream into a queue-backed store as they land. The results view puts award, card-program, and market prices side by side — so "book the award, pay cash, or use the card" is answered on one screen.

Three slices of it were mine. Flexible-date searches originally meant one search per candidate date; switching to ITA's own ±1-day windows made the named date the anchor and cut the redundant sweeps, with the UI showing exactly what each search covered. The market-price ramp — a Google-Flights-style bar showing where a fare sits in the observed range — went through several iterations before it earned its place above the results. And Copa's award fares, which first arrived by scraping the rendered page, eventually came through a proper API path; an API-vs-DOM diff script proved the two matched before the scraper was retired.

04 — The outcome

Guru is in daily production use by the concierge team. The queue has processed just under two thousand searches; a full multi-provider sweep returns 700–1,200 flight options in roughly 13–16 minutes, unattended. Fare comparisons that used to be assembled by hand across tabs are now one shareable link.

05 — What I'd do differently

Hunt for the API before building the scraper — the Copa capture worked from the DOM for weeks before the cleaner API path turned out to have been there all along. And instrument earlier: a one-day logging change comparing API and DOM fare counts settled a question that discussion alone had circled for much longer.