This year, BookingGo is undertaking two large modernisation projects. Why are we doing this? Currently, our two main systems are both monoliths, and talk to each other through a centralised database. This architecture is a tad old-fashioned and is slow, hard and complex to change. This, along with a 15-year-old codebase, means the current system cannot support the pace and growth of the business for the future.

The new projects are (1) to replace the whole web stack, and (2) to pull out the booking engine from our backend monolith. This post outlines why we are undertaking these re-platforming projects but does not cover how. Look out for subsequent posts with plans and architecture for both projects.

Web re-platforming

We’ve got some big goals for the web re-platforming project, including:

  • Allow each individual team to build, test and release independent of other teams.
  • Allow us to deliver change quicker than today.
  • Reduce the webpage speed to under three seconds, anywhere in the world.
  • Follow a device-agnostic design and build approach.
  • Combine our American and ‘rest of world’ websites.
  • Allow A/B testing.
  • Ensure no ‘big bang’ release.

Re-platforming sounds like a great opportunity to improve the UX and information architecture of the site, but we are keeping this out of scope. This may sound like a strange decision, but we A/B test every change we make to our site. If we change tech and UX at the same time, we will not know which change has a positive (or negative) impact.

To enable us to hit all the project goals, we’ve chosen to apply micro-service principles to the website. If you want to know more about the web re-platforming architecture, hosting or tech, please keep an eye out for another blog post in the near future.

Booking engine

Our current engine is bundled in with the supplier integration, call centre and other key software components. This coupling makes it harder to change the engine and report on the underlying data, alongside the other problems caused by building on a monolith.

Our requirements are:

  • Decouple the booking engine from other key business components.
  • Support multiple ground transportation mediums, not just car rentals.
  • Allow us to scale without very large VMs and large databases.
  • Reduce complexity of our tech estate.
  • Support multiple releases a day.
  • Support multi-part journeys.

There are parts of the current implementation, including business and finance reporting, that are out of scope. We’ve done it this way to reduce the size of the project and allow us to deliver software in a good time frame. We’re following an event-driven model on this project, allowing us to scale the solution easily, to de-couple our systems, and to dual-write into the old and new data sources. There is a follow-up blog coming, which will cover the architectural approach in more detail.

Where are we up to?

We started both these projects in January. From the first day of the project, we’ve been following best practice and always looking to improve our ways of working. The first deliverable for both projects was to get a walking skeleton fully deployed to the live environment and available for anyone to see – and now that that’s done, we’re putting some meat on those bones. I’ll outline more about ways of working, CD and best practice in the follow-up blogs.