Software and Technology

Travelport: Powering the search for a 360° view of travelers


  • 200
    million bookings every year
  • 850
    new passenger name records created per second
  • 4,000
    queries per second

Results 100 times faster

By using Elasticsearch, Travelport has cut its search result time from 500ms to 5ms.

Search through hundreds of fields

Travelport has gone from two searchable fields to hundreds, thanks to Elasticsearch.

Company Overview

Travelport’s vision is to redefine travel commerce. Active in more than 70 countries, Travelport connects over 400 airlines, 37,000 global car rental locations, and 650,000 hotel properties with the travel agencies that book them. When you reserve a trip online or with a travel agent, there’s a good chance that Travelport is behind it all, helping you find the best prices with biggest airlines, hotels, and rental agencies.

Powering the search for a 360 view of travelers

Travelport manages more than 200 million bookings a year — over 117 million airline tickets, 65 million hotel nights, and 94 million car rental days. And they store all that booking data on old school, but extremely powerful mainframes, a technology most commonly found in banks and government buildings. Aside from their processing power, these mainframes are so reliable that Abdoul Sylla, Travelport’s Sr. Director of Data Products, said that in the 12 years since he started working for Travelport, the mainframes have not gone down even once. The trade-off for this reliability and power is that these mainframes are designed to handle simple transactions, like ticket sales, not process intensive tasks like business analytics.

As their clients’ success increasingly depended upon delivering better target offers and bookings based on past customer behavior, so did Travelport’s need for a better analytics solution. Their mainframe solution worked perfectly for their transactional operations, but searching the mainframes by more than a few fields wasn’t an option. Nor was asking anything more than primary level questions (‘show me all the flights leaving Chicago today’ or ‘which hotels have rooms available tomorrow?’). Travelport needed to answer their travel agency clients’ more sophisticated queries (‘show me all the passengers arriving in LAX today who have traveled more than eight hours and who have no hotel booking’). And they needed to give those answers fast.

Sylla and his team of fifteen architects and developers saw the direction their industry was headed and anticipated that Travelport would soon require a new search infrastructure. Not a replacement for the existing mainframe, but a system that would run within the same ecosystem. About five years ago, they began their hunt for a faster, more flexible way to search the 200 million travel itineraries they get every year.

Finding a Way to Search Complex, Individualized Traveler Information

When a traveler books a trip, they enter a lot of information: name, birth date, gender, address, etc. This information gets attached to their itinerary (flights, hotels, car rentals, etc.), along with any itinerary changes (canceled flight, upgraded car, etc.). All this is stored on the mainframes as a Passenger Name Record (PNR). PNR data can get more complicated, though. Travel agents include remarks, memos, and notes that are captured in each PNR as free text metadata. Travelport can get up to a million metadata notes a day linked to the 200 million PNRs they get each year.

But the mainframes holding that metadata couldn’t search through the free text, rendering the valuable information within it useless. Querying beyond a name and one or two other fields required somebody writing, testing, and productionizing new code. So, Sylla defined the requirements for the new solution they needed. It needed to not just be able to hold a large amount of data, but also be able to quickly search through that data. Travelport can get up to 850 PNRs per second and they average 200-300 new PNRs per second on a normal afternoon. Their new solution also had to be flexible.

“I needed a system where I could ask for, ‘who is flying into San Francisco, arriving after 3 p.m. after having traveled eight hours or more and who does not have a hotel booking?’” said Sylla. “I want our travel agencies to be able to contact that person and say, ‘Hey, do you want a hotel booking after such a long flight?’”

Sylla’s team started with a relational database solution. But it couldn’t stand up to the volume of incoming transactions along with the need for sophisticated searches. It was too costly, too time consuming, and didn’t scale well. Back to the drawing board.

They pursued two other options: Solr, which was used elsewhere within Travelport, and Elasticsearch, which one of Sylla’s architects had used in a previous job. The team put each tool to the test and assessed each option’s throughput. In the end, Elastic came out ahead. It was faster, with better read and indexing performance. But what really set it apart — and give Travelport the edge they needed — was Elastic’s ability to perform transparent, easy to use nested queries.

Nested searching solved a nasty tangle that sometimes happened when searching the PNR data with Solr. When two people with different last names (e.g., Fred Astaire and Ginger Rogers) booked a flight together, if anybody happened to search the database for a flight booked by Fred Rogers, the search would return Fred and Ginger’s booking too. “If you can’t distinguish between the travelers, that is a big deal,” said Sylla. This limitation ruled Solr out as an option.

And then a travel agency contacted Travelport. They wanted a mobile application that would allow their travelers to manage and update their whole itineraries in one place. Flights using multiple airlines, rental cars, and hotel reservations. They also wanted travelers to be able to able to view their up to date itineraries in real time. This client app request was Travelport’s catalyst to move into production with Elastic.

Flexible Search, Text-Based and Real Time

Travelport made a prototype using Elastic to prove they could get all the PNR data out of the mainframes and search it in real time. They finished the prototype in about three months, but it took a year to complete the pipeline because of the development required to integrate with the mainframes. Once they got the PNR data into Elastic, it unlocked a new world of value to their customers.

Percolator Queries for Customer Experience

For the travel agency mobile app, they use the Elasticsearch percolator. This feature sets conditions for certain types of records being created. For instance, when a traveler makes an itinerary change from the mobile app, there’s a percolator query already in place waiting for PNR changes for certain travel agencies.

When the change hits the Elastic cluster, the traveler sees their update in the app almost immediately. By getting their data out of the mainframes and available for search in Elastic, Travelport can deliver search results that once took 500 milliseconds in only 5 milliseconds.

Demographic Data

Travelport can now tell their clients what sort of travelers are booking with them. Are they popular among the visiting grandmothers or the business travelers? Travelport's customers can use the answers Elastic delivers to better build their business strategies. And they can do this because of Elastic’s ability to seamlessly search across hundreds of fields.

Security with X-Pack

Security is important to Travelport. After they moved into production with version 5.0 in the fall of 2016, Travelport signed on for a Platinum subscription with Elastic. As part of their subscription, Travelport uses X-Pack to secure their Elastic Stack implementation. They can easily and transparently assign permissions to various accounts, allowing certain users editorial authority, while others are read-only.

Travelport is also beginning to experiment with X-Pack alerting features. They want to trigger alerts when data volume and rate change dramatically – indicating there could be an issue to solve in upstream systems. They also plan to tinker with X-Pack machine learning features to find added value within their massive data sets.

What's Next

Travelport’s first Elastic-powered mobile app went live in February 2017 and another app went live in July. They’ve been getting positive feedback and using that information to provide new services for their customers. Because Elastic has an easy-to-use API, Travelport can create new applications much faster than expected. “It’s just putting a new wrapper around what Elastic can already do,” says Sylla.

Travelport’s journey with Elastic has just begun, but Sylla is excited about their future with Elastic. He and his team have some big ideas they’re working on.

Detailed Demographic Data for their Travel Provider and Agency Clients

Soon Travelport will be able to tell travel agencies and providers how many travelers book with them in each zip code. They’ll also be able to use consolidated portraits of travelers and their travel histories to suggest flights or hotels that each traveler routinely uses as they search online. The end traveler’s search experience can be more targeted and smoother. They will find what they’re looking for — and they’ll find it fast.

Alerting Travel Groups

Travelport handles a lot of large, corporate travel groups, as well as smaller travel agencies with limited resources and right now it’s using Elastic to build a capability to allow alerting entire groups if a hurricane or other type of disaster might affect their travel, in real time.

With high speed search performance and flexible data accessibility, Elastic has helped Travelport provide new and better services to their clients. And it’s helped Travelport proactively meet the challenges of the steady, ongoing move toward mobile dominance in the travel industry.

I don’t see how else we could have done this, to be honest with you, without having this product without having the ease and the simplicity of it all.

– Abdoul Sylla, Sr. Director of Data Products, Travelport

Products Used

The Travelport Cluster

  • Clusters
  • Indexes
  • Nodes
  • Query Rate
  • Hosting Environment
  • Replicas
  • Documents
    1.3 Billion
  • Node Specifications
    16-core Linux servers, 128GB ram, 1.8 TB SSD drive
  • Total Data Size
    4 TB
  • Daily Ingest Rate
    1-1.3 million/day