Founded in 1996 in Amsterdam, Booking.com grew from a small Dutch start-up to one of the world’s leading digital travel companies. Part of Booking Holdings Inc. (NASDAQ: BKNG), Booking.com’s mission is to make it easier for everyone to experience the world.
By investing in technology that takes the friction out of travel, Booking.com seamlessly connects millions of travelers to memorable experiences, a variety of transportation options, and incredible places to stay – from homes to hotels and more.
As one of the world’s largest travel marketplaces for both established brands and entrepreneurs of all sizes, Booking.com enables properties around the world to reach a global audience and grow their businesses.
Challenge: inconsistent customer experiences and missing data insights
In 2019, Booking.com was in the middle of a major modernization initiative: migrating to a service-oriented architecture. Matt Sexton, a Solutions Architect, joined Booking.com in the middle of this modernization journey.
When he arrived, Booking.com was using monolithic services that performed data handling, business logic, and rendering for web, and a separate RESTful backend for frontend for the iOS and Android apps. This led to duplicated effort and added maintenance for their engineering teams. As Matt puts it, “Maintenance costs are much higher. Managing disparate routes meant that we needed different protocol handling and versioning, so making an update to our product required us to replicate the change multiple times throughout all the different clients using it.”
Being one of the original online travel companies, Booking.com faced considerable tech debt and code written in Perl. Without insights into how their APIs were being used, it was nearly impossible to clean up this tech debt:
“All these old fields and we did not know what was being used or not. And, we didn’t have good insight into who’s using what and when. So what can we delete? What can we get rid of? We had no way to answer those questions.”
Matt Sexton Solutions Architect, Booking.com
Worse yet, Booking.com found that customers were seeing inconsistent experiences depending on which client they were using.
And, as a team, the engineering organization at Booking.com thrives on experimentation. The department is famous for running 1000 experiments at any given time and over 25,000 experiments per year1. However, due to the limitations of their monolithic architecture, it was really difficult to confidently ensure that they were driving learning across all of their platforms.
Adopting the supergraph
From Matt’s previous experience working with GraphQL, he knew Booking.com would be a strong candidate for adopting a supergraph. In particular, Matt wanted to find a way to decouple their frontend and backend development and stop having to replicate the same feature across multiple clients. He also wanted added visibility into how his APIs were being consumed.
“We wanted to move from our monolithic architecture to a modern distributed architecture that allows us to deploy new features independently. When teams have more autonomy, the speed of delivery is greatly improved. We also want to ensure the consistency of data, access to that data, and treat all of our clients as if they are the same consumer of the same data.“
Matt Sexton
However, to operate at Booking.com’s scale, they needed a solution that would allow them to collaborate with thousands of engineers safely. First, Matt looked into building their own graph management platform but he estimated that it could take up to 12 engineers and three to five years to build a solution robust for their scale and needs. So he decided to adopt Apollo Studio to help his team immediately focus on scaling their supergraph.
Once Matt got buy-in internally to build their supergraph, he began educating the teams about its benefits. For backend teams, he focused on how challenging it was in the current system to delete a field, and how with the federated model, each team could own its own subgraph – giving them significant autonomy.
Previously Booking.com had struggled with keeping track of its different data models and structures, so he explained how the graph’s schema enables one source of truth for all their capabilities. This resonated with the developers as it would make contract testing much more efficient. Finally, he emphasized the benefits of how a supergraph layer would allow more seamless migrations in the future. “You can migrate your Perl-based REST service to a Java-based RPC and not require all of your clients to update their code,” Matt said.
To make the switch, they needed a way to migrate safely and incrementally. First, they separated their search and property pages and started requesting their data through the graph. Once the graph was stood up, they had an internal tech talk where developers using the graph shared how much easier and accelerated their work is. This helped the graph pick up traction throughout the organization. The next phase was to bring the accommodations and transport business units onto the same tech stack. Doing so with a federated graph will allow those two services to talk to each other across the business, further improving productivity.
Accelerating velocity, increasing resilience, and retiring tech debt with the supergraph
After adopting their supergraph, Booking.com was able to ship 40% faster. Matt attributes this increase to both the autonomy gained through the federated approach along with the automation and CI/CD integration.
“In some cases, teams are almost doubling the speed at which they are releasing features and we are not even close to finishing our modernization journey. There are many more ways we’re going to improve the developer experience to increase delivery frequency. We’re just getting faster and faster.”
Matt Sexton
Another benefit they are seeing from their supergraph is increased reliability:
“We are already seeing benefits of our supergraph preventing mistakes when people push a bad schema. It’s stopping silly mistakes before they happen, giving developers confidence. It’s really started helping the developers move, and they’re much happier with the experience since they can build without breaking things. The latter is one of the most important benefits of the supergraph for us.”
Matt Sexton
Booking.com is starting to retire tech debt thanks to the field-level metrics provided in Apollo Studio. With these metrics, they can see exactly what fields their clients are using to clean up unused and experimental fields with confidence.
What’s next
While Booking.com’s supergraph already powers billions of operations per month, they are still expanding its use cases. They are looking at migrating their iOS and Android apps to the supergraph. Currently, they have a search service for mobile and web, which as Matt says, “It’s the same search, so why not just bring them together?” The supergraph will accelerate this project while also helping to solve the challenges of versioning. Booking.com is also exploring how contracts could help them expose data to third-party partners seamlessly through the graph.
1 “Building a Culture of Experimentation”, HBR
Next story
Share article
