The Travel Corporation
The Travel Corporation (TravCorp or simply TTC), is a Travel and Leisure Group operating in over 60 countries with 35 offices around the world and more than 10,000 staff, serving over 1.5 million customers annually. As a Group it comprises 24 successful travel brands, such as Trafalgar Tours, Contiki, Insight Vacations and AAT Kings. The brands are independently managed and comprise tour operations, hotels and river cruise ships.
TTC has a wide and rich set of experiences to distribute to its travel agency partners and want to offer to them all the flexibility available to its own consultants and guests. To achieve this, Featurist have worked extensively with our internal sales experts and with key partners to build an elaborate and yet flexible set of services to support the searching, pricing and booking of experiences, flights and value add across six of TTC’s world’s leading travel brands. Patrick Salvi, Senior Business Engagement Manager
Our Engagement
We were contacted in 2014 by the CTO and Head of Development at TravCorp to help improve their development processes, to drive the transition to cloud-based infrastructure (AWS) and improve the delivery of new features for their travel booking site.
We initially started work on improving the Booking Engine, Travel Corporation’s consumer travel booking site, we explain our successes on this below. We also began the transition from an entirely on-premesis datacenter to one that took advantage of AWS, allowing more flexibility in infrastructure architecture, more isolation between teams in test and development environments, and meant that teams could release to production earlier and more frequently due to simplified hardware provisioning.
Following these initial projects, and having understood the challenges faced by the Travel Corporation with its existing technical landscape, we proposed we embark on a new project: a total rethink of how the Travel Corporation quoted for tours, which eventually led to a complete overhaul of their public API and technical strategy. We describe these 3 projects below, with other pages describing our more technical approach on automated testing, how we created new isolated environments for each workstream and more.
The Booking Engine
you can access the booking engine by booking a tour through Contiki, Trafalgar Tours, Insight Vacations and other brands.
The travel booking site, known internally as the Booking Engine, is where all online tour sales are made. Whereas the brand sites allow users to browse and search for tours, the Booking Engine is used by all brands to give users an up to date quote, allow them to select additional options such as hotels, flights and apply promotions, and pay and confirm the booking for the tour. It receives 2-3k unique users per day.
The Challenge
TravCorp had identified a number of areas of UX improvement for the Booking Engine and wanted a design refresh to better match each of the travel brand sites that used it. Part of the challenge for adding new features to the Booking Engine was that it was developed in tandem with a much larger backend project that was released on a monthly basis following a battery of manual tests and release protocol, this made the development process slow and gathering feedback from new UX changes frustrating.
A Rewrite
After having released a number of new features in the old Booking Engine, we made a review of the codebase and had several discussions with the developers at TravCorp. We decided to rebuild it from the ground up, and more importantly, to back all features up with a solid suite of automated UI tests that gave us the confidence to release new features within hours not weeks.
The Result
The result was that we had a new booking engine, which was now fertile ground for new UX functionality and important changes to the booking process, and we had demonstrated to TravCorp that we could develop new features quickly and safely.
The Pricing Engine
a detailed price breakdown presented to users on the Booking Engine
The Challenge
Following the success of Booking Engine, we were keen to address one of the remaining sticking points of the booking process: that of quoting the tours. At this point, to get a quote for a tour, the user would wait some 4-5 seconds for the various backend services and databases to price up a tour, based on how many people were coming, what promotions could be applied, whether there were hotels, flights and other extras to be considered. The issue was that each quote was computed in one of the backend services with a combination of Java and SQL queries and there was no way to make this significantly faster with the existing infrastructure.
Our Solution
Our approach was to try to rebuild the pricing logic outside of the existing backend infrastructure, in JavaScript, such that the pricing logic could be executed entirely on the browser side. The insight here was that, virtually all of the pricing logic input variables, such as hotel prices, per-passenger tour prices, discounts, etc, all changed very rarely. We could simply cache these elements and recompute the prices as the users made their preferences in the UI.
We spent a good few months rebuilding what is a relatively complex pricing model. For us, 100% parity with the existing pricing logic was paramount as both the UI and the backend systems had to quote and book the tours respectively with the same price. We used a combination of strategies to achieve parity: we read a lot of existing source code in Java, C# and SQL; we used the existing pricing logic to generate prices over thousands of tours and traveler preference combinations to find disparities; we did a lot of manual testing; and once we had released, we ensured that we logged and fixed any disparities between the two systems at runtime.
The Result
Following these developments, the Booking Engine was able to compute new prices in real time as the user makes their selections while they book their tour. We have also encoded in only a few hundred lines of production JavaScript, and several thousand lines of automated tests, virtually all of the logic required to quote for a tour at TravCorp - logic that was up until now spread over dozens of different Java and SQL files with no automated test coverage.
tour quotes 1,000 times faster
Quotes for tours are now computed in 3-5 milliseconds, whereas they were previously computed in 4-5 seconds. It was obvious now to TravCorp that we could use this new technology to improve on their tour API for partners and resellers.
The Tour API
| 1400 tours |
| 3500 tour variations |
| 32,000 regional variations |
| 425,000 precomputed prices |
| 40 daily users |
| 90,000 hits per day |
TravCorp host public APIs that are used by partners to find and resell tours on behalf of the various brands. There are dozens of partners who use the APIs in different ways: some of them use the API to generate ads for individual tours using affiliate links to generate revenue, some of them have sites that agregate tours from a variety of different operators including TTC, some of them allow their users to browse, book and pay for tours. There are over 1400 tours and 3500 tour options available across all of the brands, mapping to over 32000 different market-regional and seasonal tour variations.
The Challenge
The problem was that of the different APIs available and used by their partners, none of them were ideal for a lot of use-cases. One API was relatively well built and structured, but was only available for a small subset of available tours. One API required users to download content for 3 hours a day to get the latest tour availability and prices. Another was extremely comprehensive in what it provided, but tour availability was not frequently updated. All of these APIs suffered problems organising the tens of thousands of tour variations into tour products that users could understand and navigate.
Tour data at TravCorp is inherently multi-dimensional. There are variations of tours, such as whether the tour includes a 3 day or 7 day cruise in the Greek islands. There are market-regional variations of tours, with itinerary differences when sold to the US-based or the Australian markets for example. There are also improvements and changes of tours from one season to the next, i.e. we might have a summer 2019 season, winter 2019 season, summer 2020 season, etc. There are approximately 32,000 of these variations currently selling and our job was to make these 32,000 tours comprehensible and navigable to the average user, via a new API that could be used by TravCorp’s own brand sites and their partners alike.
Our Solution
Our approach was to analyse the tour data and find groups of related tours that made much more sense to TravCorp’s customers and partners. We succeeded in reducing some 32,000 tour variations down to 1,400 distinct tours, with 3,500 add-ons or options, with comprehensible relationships allowing users to select for e.g. how long their Greek island cruise was, or if they wanted the Sailing as part of the tour or not. This is something that had previously required a lot of insight and data processing on the part of the brand or partner integrating with the API.
With this scale of data, we faced a large challenge in making sure that this data was accessible by API users in a performant and reliable way. With much of the data stored in a regular SQL database, it would take literally hours to query all of it at once, hardly practical for an API over HTTP. Our solution involved a large amount of caching of course, but we had to understand which elements of the data changed more frequently and which less frequently to ensure the caches were rarely if ever stale.
We decided to run a background process to load and produce prices for all of the 425,000 individual tour dates in the system, this is something that typically takes a couple of hours per day. We also wanted to ensure that the data update happened atomically, so API users didn’t get mixed results if they requested the data while we processed the update, and above all we wanted to ensure that our API users had a reliable and performant experience using the API over HTTP.
The Result
some of the API endopints you can browse from the API documentation
The result is that TravCorp’s partners and travel agents are now able to access and make sense of the thousands of different tour variations available across different sales regions, understand the different tour options available for each tour, and get instant and up to date quotes for each tour date. TTC’s partners have access to all this information in only a few seconds using out API, which they can use to fill their own search indexes that power their own sites. The API also gives the latest tour availability, the ability to book those tours, pay for them, manage bookings post-sale and provides an OAuth authentication flow to allow invidual travel agents to login.
It is currently in daily use by more than 40 different partners and resellers and has become the corner-stone of The Travel Corporation’s strategy for the future development of its own brands sites and consumer-facing sites. The API currently receives new features from multiple internal tech teams, all of them who rely on a comprehensive but fast suite of automated tests to give them confidence to release on a daily basis.
This project provided the first step in the transition to AWS from our heavily on-prem based architecture, tightly coupled with legacy systems and complex product structures. Our engagement with Featurists allowed us to simplify architecture to leverage cloud capabilities. In addition to that it helped simplify product structures for API users and ultimately our customers. Aadil Qayium, Software Delivery Manager
Our Technical Approach
We did a lot of work at the Travel Corporation so we’ve written up more detail on our technical approach on other pages:
