Wayfarer Collective

Mobile application

The challenge

Wayfarer's search took 8-14 seconds because it waited for all 40 supplier APIs before returning anything, and a single slow supplier degraded every search. Worse, disruption handling was entirely reactive: when a flight cancelled, travelers found out from the airline, then called Wayfarer's support line, which was where the queue formed. A single European storm generated 4,000 support contacts in eighteen hours and a service-level breach across a third of enterprise accounts.

Research

• Latency and reliability profiling across all 40 supplier integrations over 60 days
• Analysis of support contact volume and content during six historical disruption events
• Traveler interviews on what they actually want in the first ten minutes of a disruption
• Policy compliance analysis identifying where travelers went out of policy and why

The solution

Search returns progressively: fast suppliers render immediately while slow ones stream in, and any supplier exceeding its latency budget is dropped from that search rather than blocking it. The disruption engine subscribes to supplier status feeds and detects affected itineraries before the traveler does — for 78% of disruptions it identifies and books a replacement automatically, notifying the traveler with the new booking already confirmed rather than asking them to choose. Travelers who want to choose can override.

UX decisions

Features

• Progressive multi-supplier search with latency budgets
• Automated disruption detection and rebooking
• Policy-aware results with inline approval routing
• Price-freeze with explicit revalidation semantics
• Traveler mobile app with live itinerary status
• Spend, compliance, and carbon reporting per client
• Supplier feed configuration with per-feed circuit breaking

Technology

Architecture

A Go search service fans out to supplier adapters with per-supplier latency budgets and circuit breakers; results stream to the Next.js client over server-sent events as they arrive. Redis caches supplier responses with short TTLs tuned per supplier volatility. Supplier status feeds land in Kafka, where a Python disruption service matches events against active itineraries and triggers the rebooking flow. Booking state lives in PostgreSQL with saga-based coordination across suppliers, since a multi-leg rebooking can partially fail and must unwind cleanly. Runs on GKE across two European regions.

Results

Disruption support contacts fell 66%. The disruption engine resolves 78% of affected itineraries without human involvement. Search latency dropped from 8-14 seconds to 1.2s at p95. In-policy booking rose 24%. During a storm event comparable to the pre-deployment baseline, support volume was roughly a third of the prior incident with no SLA breach.

Lessons learned

1. 01Leading disruption messaging with the solution rather than the problem was a copy decision with an operational-scale effect. It is the single change most responsible for the contact reduction.
2. 02Per-supplier latency budgets required accepting incomplete search results, which product resisted initially. Completeness was worth far less than speed to actual travelers.
3. 03Saga-based booking coordination was more complex than we wanted and unavoidable. Multi-leg rebooking fails partially often enough that anything simpler leaves travelers in inconsistent states.