Contact us View @ address


# travel & hospitality

Europe’s leading SaaS solution for the digitization of tours and activities



faster responses for an API request

33,000 +

attractions in Europe which can be booked in real time


place in Digitalization of CX category (Digital Champions Award)

problems to solve

bookingkit is one of the leading Berlin-based companies from the leisure industry, highly recognized in the sector. The company operates as a neutral Global Distribution System (GDS) to provide travel agencies and marketing networks access to tours and activities in the form of a digital inventory. It is also a web-based and integrated solution (software as a service) for providers of tours and activities.

We were approached with an idea depicting how they would like to change their platform’s architecture to enable scaling it even further. The chosen solution is based on sharding - creating a number of instances sharing the same codebase but with different datasets derived from the source and divided by the chosen factor.

Such an approach, similarly to Microservice architecture, creates certain challenges like:

  • providing API access allowing data consumption, 
  • creation across all the instances like it would be a single application.

That can be achieved for instance by creating an API gateway in front of the application instances, and that is what we aimed for.

In addition, a solution had to:

  • meet certain performance criteria in terms of response speed,
  • be flexible to allow for further development of the main application, 
  • scalable to support the growth of the user base and possibly the number of instances.

All of this has to be highly available - bookingkit is working with demanding partners such as Trip Advisor or Get Your Guide, which means their services have to be available 24/7.


When you’ve been building a platform for years it is not easy or sometimes even viable to go from a monolith to full microservices right away. Such an operation could consume too much time and resources and basically is quite risky. But an API Gateway is a necessary step forward in creating a distributed system. The new service should do everything that the bookingkit’s API could do. 

So we then, we knew the issues and the main goal. The question that stood was: “How exactly are we going to achieve that?”. To find the complete answer couple of steps were needed. It all started with an intensive technical workshop

The first concept we’ve discussed was creating a service that would not only mimic the existing API but would also be a copy of the whole database, in that case combining all the data that was supposed to be sharded into a number of instances connected to it.

After the workshops and a couple of talks, it became apparent that we should validate the assumptions with a Proof of Concept (the chosen tech was Flask, a Python framework). The results were somewhat pleasing, but still, we saw potential issues with performance, overall high complexity of the new service and other risks regarding data integrity and migrations.

Another technical meeting was held in our office after which it was decided to verify the lighter version of the service. Only this time it was supposed to “just” relay all the requests to the instances behind it and combine the responses into one. Also in search of better performance, this time we’ve decided to compare two techs - Python and Golang

That was the moment when it “clicked”, not only had we confirmed the solution to be the right fit, but we also found that choosing Go can yield surprisingly better results - the TTFB was twice as fast as the solution using Python.


Verified concepts:

  1. (proof of concept 1) Creating an API service next to bookingkit - requires replicating current API and database in a new service - issues: database synchronization concerns, data migration, latency
  2. (proof of concept 2) Creating an API gateway proxying the requests from the Internet to all instances of bookingkit application and serving unified responses - quicker to implement, fewer concerns about data consistency

Considered technologies:

  1. Python (flask) - turned out to be too slow compared to Golang, response latencies were too long
  2. Go - it was a lot of faster than python, relatively fast in implementation, “built-in” asynchronicity

API gateway proxying and aggregating data to/from instances was created. The programming language chosen was Golang, infrastructure that was also a big part of the solution is in AWS (AWS ECS), we also prepared robust CI/CD pipeline with automated tests of the whole API written in Cypress, automated performance tests in k6, automatic deployment from the pipeline to staging/production environments. Everything was also automated in Terraform.

view examples

Diagram 1 - The steps undertaken by Merixstudio
Diagram 2 - PoC process

key features

  • API Gateway concept was verified

    we’ve established that the Gateway pattern will be suitable for this project covering all the functional requirements and being lightweight

  • infrastructure was planned

    the initial plan for the infrastructure set-up was conceived - our non-functional requirements covered usage of AWS services, high-availability and possibly low response latencies

  • programming language recommendation

    Go is the way to go! The application written in Golang provides twice as fast responses for an API request than the one created in Python/Flask.

  • measurable parameters established

    specific Gateway response latency measured in TTFB (Time To First Byte) become our key goal to be met.

other works

Brevo (ex Sendinblue) flag of Brevo (ex Sendinblue) country

Brevo (ex Sendinblue)

The all-in-one marketing platform
react redux php symfony product scale up
media & entertainment
Logo Creator flag of Logo Creator country

Logo Creator

ML-powered logo maker to instantly create custom logo designs
react python django proof of concept
media & entertainment
When will building custom software bring the most value to your business?
When to go for building custom software?
4 common cases in which going for custom-built software will maximize the value derived from implementing it. WATCH THE VIDEO GUIDE

We use cookies on this site to improve performance. By browsering this site you are agreeing to this. For more information see our Privacy policy I understand