Booking Tool: A reengineering journey from a legacy monolith to microservices

Stanislas Nichini
Feb 16 · 11 min read

Author: Stanislas Nichini, Software Engineering Manager at Groupon

Booking Tool — a monolith application built in 2014

One of Groupon’s key priorities is to have a frictionless booking experience for our merchants and customers. Booking Tool plays an important role in this strategy by providing a free booking management application to our merchants in International and North America. But this tool was not only originally focused on our merchants but also on our customers and operational teams. Booking Tool originated from Groupon’s French engineering team in 2014. The application was initially built for the French and German local markets and especially for the Food and Drink industry. The tool was originally used by 100 merchants in France and Germany where 500 deal options were bookable on the platform.

By the end of 2014, merchants from France, Germany, Italy, Spain, The Netherlands, and the United Kingdom were using the Booking Tool. More than 15,000 bookings were made by customers and more than 470 merchants launched 2100 deal options. This was the beginning of the Booking Tool journey.

The expansion of the tool among all International markets continued until 2020. It was launched in test markets like South Africa, Hong Kong, Brazil, Singapore, Sweden, Malaysia, Switzerland, Argentina, Denmark, Portugal, and Norway.

More than 23 million bookings were made since the launch in 2014!

365k+ deal options across all markets

>60k merchants onboarded

As of today, the Booking Tool is available across all the International and North American local markets. In September 2019, the tool was launched in North America. More than 2500 merchants are now bookable!

Booking Tool, a multi-headed beast that needed to be reengineered

The monolith tool became an increasingly complex and sophisticated platform. But actually, the legacy tool had multiple heads:

So why did we want to re-engineer and improve the platform? First of all, the tool lived outside the Groupon platform but also was:

How to transition from this legacy monolith architecture towards a microservices architecture? Before answering this question, the team came up with the following requirements:

The “Chicken Little” Incremental Migration

To tackle the transition from the monolith tool to several services, the team applied the incremental transition strategy called the “Chicken Little” approach. This approach comes from the analogy with the very cautious and conservative Walt Disney hero. The overall idea and methodology are described by Michael L. Brodie and Michael Stonebreaker back to the 90s in their book “Migrating Legacy Systems.” The migration consists of 11 steps that can be done in any order and parallelized and can be skipped.

The key is to perform each step “incrementally”:

The benefits of Chicken Little reside in:

There are risks attached to this transition:

The Booking Tool migration plan and cycles

For each cycle and step of the migration of the Booking Tool, the team adopted the “Chicken-Little” incremental approach.

to explain the value of each cycle, we also added 3 major rules:

Satisfy users and business objectives

This rule defines “why” this transformation is needed.

The question is: What is the measurement of the success of this cycle?

Each deliverable needs to be measured against one (or several) metric(s) of success (KPI: Key Performance Indicator).

This can be a measure of :

Most important objectives first

This rule defines “how” to do the transformation.

The question is: What are the key components that are indispensable and mandatory for the success of each cycle? What is the goal? The Product and Engineering groups work hand in hand with a common goal: To make our Groupon local merchants bookable. To ensure our success, the team identified the most important priorities:

From an engineering perspective, we followed the same route as business and product. We aligned our goals and objectives to tackle the transformation.

Decomposition into independent operational deliverable milestones

This rule defines “what” to do during the transformation.

The question is: What are the deliverables of each phase and do they interact with the overall engineering picture? What is the purpose of each cycle? Each system or component needs to be delivered and launched at the end of each cycle. Smaller milestones can also be set to launch part of the components. I The sooner it’s deployed, tested, and used, the sooner you’ll receive feedback from the users. The sooner you’ll be able to correct, troubleshoot, and improve the system. What are the dependencies of this component? Is there any other migration depending on the success of the deliverable?

The plan


The transition plan started in May 2018 and is scheduled to be completed by the first half of 2021.

The progress

To begin, the Product and Engineering teams decided to build a new customer experience as part of the purchase funnel on Desktop, Touch, and Mobile, allowing a seamless experience for the customer. The customer will be able to see the availability of a deal, pick a date and a time, and book their experience as part of the transaction.

In June 2018, the first step of the migration began. This was our architecture before:

Booking Tool high-level architecture pre-migration

And our target:

High-level architecture post-migration

Not all deals benefited from this change as some setups are complex and require, for example, the phone number or comment to complete the booking. Other deals are multi-session or travel oriented. Finally, some deals are bookable on multi-locations.

The MVP excluded these complex setups. The deal coverage was above the 60% mark.

The Squad Ownership

Squads ownership

To tackle this reengineering project we had, over the last 2 years, 6 major teams or “squads.” This article won’t go in-depth about the squad model but I wanted to highlight some of the key aspects of this ownership model. The squad is defined by:

We also had some special squads that helped things to go faster and bring the product to life: SWAT and Acceleration team. One other key essential aspect was the cross-collaboration between squads. Having multiple services and multiple teams, we had to find solutions to facilitate:

What did we learn?

Throughout the last 30 months, the different teams, squads, and stakeholders learned many important things:

Fail Early and Fast to Learn Faster

Launching a new application from scratch and learning from its users is key but we also need to know early and rapidly if it’s a success or a failure. The entire research, design, architecture, development, deployment, and launch processes for the MVP of the new merchant application lasted 6 weeks. The first feedback from our merchants and sales representatives were walked through early. We were able to adapt to their ideas and we knew what needed to be changed. We ditched some undeveloped functionalities, re-evaluated some, and simplified others. We learned from different markets and business pitch sessions on site. We finally postponed launches and prioritized others using business KPIs (key performance indicators). We were able to learn from some mistakes and we were nimble enough to address our merchants’ needs.

Make it work, Make it right, Make it fast: Kent Beck

Related to the previous learning, our primary goal was to make our application work by:

Since then we are still in the process of making it right:

The teams are starting to work on the last rule, making the application fast, more reliable, smart metrics, profiling, scaling, and alerting.

Squads framework: Spotify model

Along this reengineering journey, the team’s structure and framework also evolved. We are still in the process of the Agile transformation at Groupon.

Our Product and Engineering groups benefited from this transformation early. The teams operated at a fast pace, almost like a small startup within the organization. It allowed us to be very efficient and to remove our roadblocks quickly. There is still a lot of work to be done to transform the entire organization but this helped our project to be achieved step by step. Being aligned and autonomous were and still are two key values at Groupon.

Innersource model

This learning is still fresh but the Innersource model is supported by our engineering leaders and owners to become a standard at Groupon. The teams applied this model to our two new applications: Merchant Booking Tool and BOTS. Other teams are able to build the necessary features and contribute to the codebase. This change cannot happen overnight but it will surely grow in the future.

Business Operational vs Application vs Infrastructure metrics

These 3 metrics are very important and complement each other. We need to know when the servers are down, when the CPU load goes beyond the threshold, or when the database has a sudden spike of parallel threads. We also need to understand when we have errors, uncaught exceptions, API dependency failures, and so on. But we should not neglect the importance of business and operational metrics. The operational business metrics are useful to detect when something is wrong over time. It can be negative or positive. These metrics are key to understanding why a feature is successful, or why there is something wrong with the application. For example, you could suddenly have a drop of bookings compared to last week, a feature not used as frequently as last month, a refund rate going up by 30% for a given vertical or category.

What’s next?

Our journey is not over yet! Our teams are continuing the platformization project of the booking customer experience. We have also entered the deprecation phase of our legacy monolith:

We are targeting to remove the plug of the legacy monolith before the end of 2021!


Groupon Product and Engineering

All things technology from Groupon staff

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store