DEV Community

José Catalá
José Catalá

Posted on

Three Ways to Fly: Building Route Options Ranked by Time, CO2 , and Reliability

#node #javascript #webdev #aviation

Three Ways to Fly: Building Route Options Ranked by Time, CO₂, and Reliability

Tags: aviation, webdev, javascript, node

We just shipped the Routes tab on MyAirports. You pick an origin and a destination, and you get up to three connecting itineraries — one optimised for total travel time, one for CO₂, one for reliability. Each card shows the hub sequence, layover breakdown, ticket type, and the per-leg airline strip.

Building it meant solving a set of problems that are more interesting than they look. Here's how the system works.

Routes as views, not entities

The first design decision was the most important: we don't store routes.

The existing pipeline already produces Flight records from scraping, DelayStats from nightly aggregation, and RouteStats / AirlineRouteStats from a weighted recompute. The routes system is built entirely on top of those — it's a graph and a ranker layered over data that already existed.

The alternative was a routes table with its own write path. That would have meant migration risk, dual writes, and a whole new ingestion concern. Instead:

Flight (scraped)
  -> DelayStats (nightly per-airline-per-route-per-DOW)
    -> RouteStats + AirlineRouteStats (nightly recompute)
      -> Graph (24 h in-memory cache)
        -> Candidate BFS (≤ 2 stops, 2× viability filter)
          -> Leg durations + hub layovers
          -> Three-bucket ranking
            -> /routes/indirect response
Enter fullscreen mode Exit fullscreen mode

Every layer already existed. The routes feature cost zero new ingestion work.

The graph

The in-memory graph lives in api/src/graph/build.js. It's a two-level adjacency structure:

// edges: Map<origin, Map<dest, airlineIata[]>>
Enter fullscreen mode Exit fullscreen mode

Built once per process, cached 24 hours. Each airport gets a hubScore — the sum of its incoming and outgoing route counts. That number drives minimum connection time later.

The graph rebuilds nightly after AirlineRouteStats updates, so it never goes stale relative to the underlying data.

Candidate enumeration: the 2× viability filter

The BFS expands up to 2 stops. The question is which of the potentially enormous candidate set to keep.

The filter is a single line:

function isViable(totalKm, directKm, factor) {
  if (directKm <= 0) return true;
  return totalKm <= directKm * factor;  // factor = 2.0
}
Enter fullscreen mode Exit fullscreen mode

Any path whose total great-circle distance exceeds twice the direct distance is dropped immediately. This eliminates the LHR → JFK via NRT class of nonsense before any scoring happens — and it handles ~99% of pathological candidates.

Within each depth level, we keep the top 20 candidates by aggregated flight frequency, then return the shallowest non-empty level. A direct flight will always beat a 1-stop. A 1-stop will always beat a 2-stop.

Leg durations: physical plausibility filtering

For each leg, we compute the median observed flight time from the last 30 days of Flight records. But raw scraped durations are noisy — airport systems sometimes emit 00:00 or obviously wrong values.

The fix is an airspeed window:

const MIN_SPEED_KMH = 150;
const MAX_SPEED_KMH = 1100;

function isPlausible(durationMinutes, distanceKm) {
  const impliedSpeed = (distanceKm / durationMinutes) * 60;
  return impliedSpeed >= MIN_SPEED_KMH && impliedSpeed <= MAX_SPEED_KMH;
}
Enter fullscreen mode Exit fullscreen mode

Anything outside 150–1100 km/h is discarded as a scrape artefact. A flight slower than a fast car or faster than a commercial jet can't be real. This is cleaner than maintaining a per-airline median lookup table.

Hub layovers: matching real arrival/departure pairs

This is the part I'm most pleased with.

The naive approach is to add a fixed layover estimate — 90 minutes, say. The problem is that 90 minutes at Frankfurt is different from 90 minutes at a small regional airport, and neither is the same as an overnight connection in Singapore.

Instead, we match real pairs:

  1. Pull all arrivals at the hub from the origin airport (last 30 days).
  2. Pull all departures from the hub to the next-leg destination (last 30 days).
  3. For each arrival, find the closest departure that respects the minimum connection time. Allow next-day pairings.
  4. Median the gaps. Track overnightPct. 
// Minimum connection time is hub-score-driven
function getMCT(hubScore) {
  if (hubScore > 500) return 90;   // major international hub
  if (hubScore > 100) return 60;   // mid-sized hub
  return 45;                        // smaller airport
}
Enter fullscreen mode Exit fullscreen mode

If fewer than 5 pairs match (new route, sparse data), we fall back to MCT + 30 min and mark the result estimated: true. The UI surfaces that flag so users know the layover is a model estimate, not observed data.

The overnight detection falls out for free: if ≥50% of matched pairs cross midnight, the card gets an overnight badge.

Reliability: geometric mean, not arithmetic

Each leg has an on-time percentage from AirlineRouteStats. The combined reliability for a multi-leg itinerary is:

combined = (Π onTimePct_i / 100)^(1/N) * 100
Enter fullscreen mode Exit fullscreen mode

A 95% first leg and a 60% second leg gives 75.5%, not 77.5%.

This is the correct model for passengers. An itinerary is only as reliable as its weakest leg — a late arrival on leg 1 threatens the connection on leg 2. Arithmetic mean treats reliability as independent; geometric mean treats it as compounding. The difference matters most on long hauls with tight connections.

Legs without sufficient sample data are skipped (not zeroed). Zeroing them would unfairly penalise routes with new airlines.

Ticket type detection

For each candidate itinerary, we intersect the airline sets across all legs:

const legAirlines = legs.map(leg => new Set(leg.airlineIatas));
const intersection = legAirlines.reduce((a, b) => new Set([...a].filter(x => b.has(x))));

const ticketType = intersection.size > 0 ? 'sameAirline' : 'selfTransfer';
Enter fullscreen mode Exit fullscreen mode

If the intersection is non-empty, a single-ticket booking is possible. The card shows a "Same airline" badge. This is a meaningful signal for passengers — a single PNR means the airline is responsible for the connection; a self-transfer means you're on your own if leg 1 is late.

The three buckets

The ranker (api/src/graph/ranker.js) produces exactly three outputs:

  • Fastest — minimise flightMinutes + layoverMinutes
  • Lowest CO₂ — minimise totalDistanceKm (CO₂ is derived from distance per passenger, per ICAO methodology)
  • Most reliable — maximise combinedOnTimePct

The same itinerary can win multiple buckets. In practice that's rare — the fastest path is usually not the shortest, and the most reliable is usually neither.

There's one tiebreaker: within 10% of the bucket's winning metric, prefer sameAirline: true over self-transfer. This only fires when two options are essentially equivalent — it never overrides a meaningfully better route.

CO₂: distance is a reasonable proxy

CO₂ per passenger varies by aircraft type, load factor, cabin class, and whether you count radiative forcing. We don't have that granularity — we have distance and passenger counts.

The proxy we use is total route distance (sum of all legs). This correlates strongly with actual emissions for the comparison use case: a 4,000 km itinerary via one hub emits less than a 7,000 km itinerary via two. The absolute number is an estimate; the relative ranking is reliable.

Future improvement: when we have aircraft type data per route, we can use the ICAO carbon calculator's per-type coefficients. For now, shorter is greener.

What surprised me

The overnight detection rate is higher than expected. On intra-Asian routes and certain long-haul pairings, a meaningful fraction of practical connections require an overnight stay at the hub. The flag matters — nobody wants to book what looks like a 6-hour trip and discover it's actually 18 hours with a hotel stop.

The viability filter is doing more work than anticipated. Without it, BFS over a 1,300-airport graph at 2 stops produces thousands of candidates per query. With the 2× cap, it drops to tens. The entire indirect query runs under 50ms even with the layover matching.

And the geometric mean genuinely changes rankings. There are routes where the "obvious" hub (higher on-time per leg) loses to a less-used hub because one of its legs has a 55% on-time rate that drags the geometric mean below what an arithmetic average would show.

What's next

The direct route page (per-route delay stats + airline comparison) is live but Pro-tier only. The indirect routes explorer is public. The obvious next steps are:

  • Aircraft type integration for more accurate CO₂ estimates
  • Full status timeline (not just on-time%, but delay distribution) for the reliability bucket
  • Price integration — the fourth bucket nobody asked for but everyone wants

The Routes API is available at myairports.online/developers. GET /routes/indirect?from=LHR&to=BKK will give you a sense of what the output looks like. Free tier: 100 requests/day, no card required.

Top comments (0)