What is flight route optimization?

Standard flight search: one query, one answer

Every mainstream flight search engine — Google Flights, Skyscanner, Kayak, the airline's own site — is built around a single shape of query: origin, destination, outbound date, return date. You type those four values in, the engine queries inventory, applies your filters, and returns a ranked list. For roughly 80% of leisure trips that works perfectly. Two airports, two dates, one constraint: "cheapest reasonable schedule."

The problem isn't that those engines are bad. They're fast, free, and almost always correct for the trip-shape they were designed for. The problem is what happens when the actual trip you want to take doesn't fit that shape — a third destination, a flexible city order, a school pickup on Tuesday, three viable home airports, a willingness to accept a stopover if it saves $200.

Combinatorial search: many queries, one ranked answer

Route optimization inverts the question. Instead of "what's the price of this exact itinerary?", it asks: "among every valid permutation that satisfies my hard rules, which is cheapest?" For a single round trip there's basically one permutation, so combinatorial search adds no value. For a three-city trip with a flexible order, two nearby airports per city, and a ±3 day window, you're suddenly looking at hundreds of permutations.

Concretely, for n destinations, k airport alternatives per city, and a window of d days, the number of distinct routings grows on the order of n! × k^n × d. Three cities with three airport options each and a 5-day window already produces over 800 valid itineraries. No human is going to retype that into a search form 800 times. That's the workload a constraint engine is built for.

What "valid" means

The interesting word in "valid permutation" is valid. A combinatorial engine isn't just running every possible flight combination — it's filtering against the trip's hard rules first. Things like:

• Arrival before a fixed deadline (a wedding, a Monday meeting, a school pickup)
• Party size and bag count (some fare classes don't have award space for four people)
• Religious or schedule constraints (no Shabbos travel, no overnight red-eyes with toddlers)
• Layover floors (no connections under 90 minutes; nothing over 6 hours)

Anything that fails those rules is discarded before it's even priced. The remaining itineraries are then queried against live inventory, ranked by total cost (sometimes weighted by total time or comfort), and the top results are surfaced with the booking order that locks the savings in.

Why mainstream tools haven't done this

Mainstream flight search engines were built for scale and speed. Their UIs are optimized for the 80% case because that's where the volume is. Adding a constraint solver in front of every search would slow down the simple cases without helping them. So the optimization layer has migrated to specialized tools — corporate travel platforms, award-booking services, and now consumer-grade tools like SnagRid — that only run when the trip-shape is complicated enough to need it.

When optimization actually pays off

Route optimization is overkill for a one-leg round trip. It pays off when:

• You have three or more destinations
• City order is flexible
• You have multiple viable home airports (NYC, London, SF Bay, LA basin)
• You have a hard deadline that turns "cheapest" into a constraint problem
• You're open to a free stopover via a transit-friendly carrier

If two or more of those describe your trip, you're in territory where mainstream search will materially under-serve you — not because it's broken, but because the question you're asking is no longer the question it was designed to answer.

The TL;DR

Standard flight search prices itineraries. Route optimization searches for them. Both are useful, but they solve different problems. For 80% of trips, mainstream search is the right tool. For the other 20%, combinatorial search is the difference between booking what you found and booking what was actually available.