How Amadeus is using MongoDB to keep the world moving
Amadeus CTO: "We want to provide a much more personalised travel experience that is much more connected and is instant."
When you take a flight anywhere in the world, the technology that shows you the options available, that books the flight, that handles everything from check-in through to hotel reservation, will likely be run by Amadeus.
ZDNet talked to the CTO of global operations at Amadeus, Olaf Schnapauff, to find out how it's done, including its use of the MongoDB technology.
Amadeus is a massive operation. How does the database technology at its heart fit in?
Amadeus's Schnapauff: "We have clusters that are tens of terabytes in size and tens of terabytes in throughput. We had a cluster that grew from three servers to 42 servers in nine months."
Schnapauff: Amadeus provides the technology that keeps the travel sector moving. From the initial search to find what you want, to making a booking, to pricing, ticketing, reservations, check-in and departure, hotels, rail, and the overall travel experience.
Even though most people are unaware, almost everybody travelling has used Amadeus for their travel needs. We aim to facilitate the complete travel experience from door-to-door.
Now when it comes to travel, people's expectations have definitely changed. We are a very big system. We handled almost 450 million passengers in 2015, 4 million booking at peak times each day, and so the demand on our technology had always been extremely high.
We need to be very reliable; we need to be very trusted and very secure. We need to be extremely high performance in latencies and throughput, but we also have to adapt to the reality that the travel experience that people are expecting had changed.
In the past you went to a travel agent and you had a discussion and maybe got a few ideas from the travel agent. Once that was done, the travel agent started to do some queries, look around a bit -- what's available, what are the prices, etc -- and then make the booking.
Today, the whole experience that people expect is quite different. For example, I am a scuba diver and, say, I want to go diving and I am not sure where I want to go. So I will Google and look for suggestions and find ideas of where I want to go and get results back. And, these days, I will look at some of the numbers involved and I might cringe when the system tells me it is looking at 50,000 sites for me when all I need is one and maybe I will look at 10.
Today what we call the "look-to-book" ratio has exploded. There is a lot more looking around, a lot more results back and so on.
Now the Instant Search feature that we are introducing, which is based on MongDB, really helps the customer get what they want and what they need. Today's generation doesn't accept the old way of working -- put your choices in and go for a coffee while you wait for the results. That's not how things work any more and results have to be instant.
One of the issues today must be the sheer volume of requests, so over time have you ramped up the size of your processing operation?
It's true. We have seen quite some growth and we are a public company so you can look up quite a few of our commercial numbers. [A billion transactions a day, 8 petabytes of storage, 10,000 employees worldwide].
But it's not just that the volume of travel that is increasing, it is the behaviour that is changing. There are no longer simple time-of-day queries. Customers are looking for a much wider search experience. We find that 25 percent of travellers have not really decided on a destination and almost half don't even know the date they want to travel on.
The new queries are more like, 'I have $600 and I want to go diving somewhere, so where can I go?'
It's a much harder task for a computer system to answer that kind of query. It's not just about looking up a table.
We want to provide a much more personalised travel experience that is much more connected and is instant. For us, instant means giving customers results in milliseconds. That is why we are looking at MongoDB for complex searches across multiple dimensions.
What we want is for the software to handle these multi-dimensional queries and handle those queries in real time.
The Instant Search feature was originally developed on our internal NoSQL databases. Now a relational database really couldn't handle the level of complexity required on the scale required.
Now this was really one of the strengths of MongoDB -- the scale that MongoDB is capable of along with the data governance and distribution capabilities. We are also getting the performance that we need, the storage engine compression that we need, and that really feeds the level of confidence that we have.
And we are really using all of the security and the privacy offered. We are often dealing with sensitive information. Yes, a lot of it is public like the flight schedule and so on, but other information can be highly sensitive and we treat it that way.
Why did you choose MongoDB?
There are a number of factors when you pick a partner. First of all there is the technology fit. The technology challenge that we have is handled very well in MongoDB, including security manageability and scalability that are key factors, and the feature set.
Of course it also has commercial implications as a product choice and last, but not least, was knowing the right partner. What we were doing was innovative and new, so we needed the right partner who could understand what we wanted and could go with us on that journey.
We wanted to do great things for the travel industry together with someone. We didn't want a pure supplier relationship, we wanted a partner. It's not just a matter of taking something off the shelf, but of taking that partnership and shaping it. KAYAK.com [the hotel booking system] is already showing what that looks like.
Is it difficult to come up with the right way to describe these next-generation database technologies?
That's true. The whole data store area is massively evolving. It's a journey that we still haven't completed. For the right use case, you need the right technology and it has greatly shifted from being almost exclusively relational databases years ago. It is now all about newer technologies that deal with today's challenges.
Those are things like better distribution, dealing with more complex challenges, new types of queries, and different levels of performance, because sometimes these types of technology are quite specialised on specific segments and they do that segment extremely well.
Right now there is no silver bullet. The complexity of what we are all trying to do is too high for any single technology.
We are always keeping our eye on these technologies but it is this shift that we see that is important. We are seeing more and more use cases for these technologies and that has enhanced the experience.
How are you finding using MongoDB in practice?
We are very happy with it. We enjoy and use the security features like channel encryption at rest, authentication, etc. All of the things we need to use to be compliant and secure.
The ease of operation and the resiliency is quite good and we are always around the boundaries of pushing automation and making it secure -- things like ease of operation and the fact that clusters are described in blueprints. Things like that are very important for us.
Scalability is good and we have clusters that are tens of terabytes in size and tens of terabytes in throughput. We had a cluster that grew from three servers to 42 servers in nine months.
We have experienced hardware failures at scale, which is not necessarily a bad thing to happen. The key thing is that they don't have a service impact because all of the servers in a stack do not rely on the hardware to do the magic.
How big is your team working on MongoDB?
It depends how you count it. We are not organised in silos anymore so there is not one Mongo team. We are running services, right? So we are in today's world when it comes to operational models.