Trivago's platform was built using PHP and their Melody framework. A small number of engineers at Trivago maintained Melody, which was a continuity risk. Melody's documentation and examples could not be as rich as desired due to a lack of capacity, making engineer onboarding and support much more difficult. Trivago then decided to rewrite its platform on Typescript using Next.js.
To mitigate the risks that developing a home-grown framework such as Melody entails, Trivago engineering had to decide whether to assign more resources to Melody or drop it. They decided to stop using Melody.
Such a platform replacement represents a risk to the business in potentially lost revenue because new features are not introduced during the rewrite period. The project started in 2020 under circumstances that already mitigated that risk.
Another risk is the loss of development team motivation once existing features are ported over, but new features remain on hold. Teams could begin to build new features once the new platform is stable enough, which reduces the risk of motivation loss.
Developer experience, hackathon results and market penetration were the deciding factors in choosing the new technological stack: Next.js with Preact using Typescript. Developers would benefit from having a cleaner code base employing widely used libraries with significant community support.
Many architectural decisions must be made while designing a new platform with new technologies. Agreements must be reached timely and pragmatically to ensure the project's success. Trivago engineers used a form of architectural decision records that Tom Bartel described as a process-based on the following:
- A decision document where all the relevant facts and viewpoints are collected and organised.
- A decision owner curates the decision document, prepares the decision meeting, and is responsible for reaching a decision.
- A decision meeting, where viewpoints are exchanged and discussed, and a decision is made at the end.
One of the most critical learnings in this project was that the team should not grow too quickly. The author noted that experimentations and course changes are easy when a handful of engineers work together; the team size should only rise above five once all crucial decisions are made and the foundations are stable. Doing so prevents communication overhead, frustration and wasted effort.
Being a rewrite, the new system needed to achieve feature parity with the existing platform. The team verified correctness by running both platforms in an A/B manner and comparing some indicators, such as user interaction, revenue generation and search types.
The author adds that the rewrite also brought benefits for the end-users in the form of faster application loading times.
