Others have replied well but I’ll add my own answer...
In order for your flight search product to be useful, you need a database containing effectively every flight in the world - all the airlines, all the destinations - and you need to update it every time a fare or seat availability changes. Then you need optimized routing algorithms to find routes that accommodate a vast array of consumer preferences. So, there are giant costs just to get access to all the data in the first place, then write the code and run all the servers.
ITA Software offered this as a service via an API, but since a couple of years after Google acquired them they stopped offering access to outsiders.
Now the GDS companies (Amadeus, Sabre, Travelport) offer API products, but they are still very costly, so big transaction volumes are needed to justify it.
There is now one way small/niche businesses can offer flight search and transactions fulfillment; a YC company called Duffel. They still only offer a narrow selection of airlines, but it’s growing.
Some other companies like Skyscanner offer access to their API, but only if it’s in their interests (ie, if you generate sales for them; you can’t make much revenue for yourself that way).
The reason Google continued to offer API access after the acquisition was because a 5 year stipulation was in the contract to get it approved by the Department of Justice. Of course once the 5 years were up that was it. ITA had also built a reservation system for Air Canada. Air Canada never used it, but Cape Air switched in 2012. In 2013, Google discontinued it.
The whole acquisition was a huge failure on the part the DoJ Antitrust Division.
The answer above has some good information, but it's also munging together unrelated topics. Flight search APIs that aggregate other, existing, APIs (like the mentioned Skyscanner and Duffel) aren't the same thing that ITA flight search or the Amadeus/Sabre/Travelport flight search engines are.
The hard problem the flight search engines solve is initially for the airlines. They have aircraft of different capacities, ranges, seat types, and so on. Then, different tiers of fares based on seat type, advance purchase, refundability, add-ons like priority boarding, bag fees, inflight wi-fi, etc. Then, a "flight" is some combination of actual flight "legs" (single takeoff + landing).
So, airlines want to maximize revenue. To do that, they set available inventory levels for many of the unique combinations of all the variables above. Perhaps, for example, only 10 of the "deep discount" point-a->b->c coach seats, but 50 for the highest priced b->c leg. Oh, and the price is higher on day "X", because some popular sporting event is held in city "c" on that day, and the morning flights priced even higher.
If you extrapolate then, you can tell that someone wanting to fly from a->c has a lot of different possible fares, with each fare having a different number of available seats to sell. And all those variables are changing underneath your search, all the time. And, you're obligated to show actual fares, including taxes, fees, etc, which vary dynamically by airport, pax type, etc.
Companies like Amadeus, Sabre, Travelport, and so on did a reasonably good job over the years of exposing APIs to both airlines and travel agents to search these. ITA came along with a more computer science based approach and made the shopping part of this much faster, with more results, flexible, more tunable by the airlines, etc.
Sure, but plenty of those jobs still around. In fact they've been struggling with the rest of the market in filling positions. AmEx travel is constantly recruiting.
The graph problem is huge (NP-complete in the full case). You can't reasonably cache things because segment availability changes a lot. Latencies on searches through the GDS may be much higher than you're used to in other domains. Due to all these factors and more, cost per query is quite high. And then on top of all that, conversions for flight searches are quite low and the reward for converting a search is on the order of single digit cents.
Basically the problem is the airlines don't want good flight search so they erect barriers, right? Airlines prefer to have pricing and route info be opaque so they can keep people using higher price options. So the infrastructure costs are about fighting to get the information from people who don't want you to have it.
On the counter-side, if there are 300 seats on a plane, worth $100 each, and everyone does 10 flight searches before booking a flight, that means that your database needs to hold a few hundred bytes about prices, the plane, and departure time, and handle 3000 queries, and for that you get a chance to make a commission on $30k in revenue.
There aren't many computing platforms that could offer a higher profit margin per byte stored or queried!
Every single one of your numbers can be orders of magnitude off. Many people search without buying, there can be hundreds or thousands of fares for a single flight, and industry margins are razor thin. If you're lucky enough to actually get a commission (unlikely), your percentage will still be junk. Skyscanner (much bigger than you) is earning in the single digit percents and I have no doubt there's a cap in many of their agreements.
Pretty much any other computing service has a better ROI.
When I do 10 searches, each of those searches hits a substantial subset of every flight that could satisfy my travel need. Suppose I want to fly BOS to LAS for re:invent. For the outbound leg, I’m probably searching for Sat through Tues, every carrier, every leg, every cabin. That means a leg BOS-SLC, BOS-ORD, BOS-ATL, BOS-LAX, etc are all considered.
You can’t easily prune the tree on cost or time because you don’t know my preferences. You might notice that most pruning is done only on segment count, with (almost?)no one by default showing itineraries with 2 additional segments over shortest. I might prefer a carrier (I do), but even if I do, I still want to see the other choices, because my preference isn’t thousands of dollars strong.
Rather than 10 queries per seat sold, I’d not be surprised if the actual query count was 10K or more.
In order for your flight search product to be useful, you need a database containing effectively every flight in the world - all the airlines, all the destinations - and you need to update it every time a fare or seat availability changes. Then you need optimized routing algorithms to find routes that accommodate a vast array of consumer preferences. So, there are giant costs just to get access to all the data in the first place, then write the code and run all the servers.
ITA Software offered this as a service via an API, but since a couple of years after Google acquired them they stopped offering access to outsiders.
Now the GDS companies (Amadeus, Sabre, Travelport) offer API products, but they are still very costly, so big transaction volumes are needed to justify it.
There is now one way small/niche businesses can offer flight search and transactions fulfillment; a YC company called Duffel. They still only offer a narrow selection of airlines, but it’s growing.
Some other companies like Skyscanner offer access to their API, but only if it’s in their interests (ie, if you generate sales for them; you can’t make much revenue for yourself that way).