We held the first Tech Stash by Mintos event on January 23, 2020 in the Mintos head office in Riga, launching our meetup series with one hundred guests from tech companies working in our ecosystem. I spoke about going from the monolith to distributed monolith, and here is a short study of our case.
If you’re a customer you may have already realized — Mintos is expanding, and it’s expanding quickly. The company has tripled the number of employees over the past year, which of course leads to a more complicated internal communications network. We can’t always tap on a teammates shoulder if we need to talk to them. According to the Conway’s Law (named after computer programmer Melvin Conway),
“organizations which design systems (..) are constrained to produce designs which are copies of the communication structures of these organizations.”
When a startup is small, the communication is rather easy and the onboarding of new people is not such a complicated process. When the scale-up onboards new people weekly, the teams can split and merge to form a distributed organization. At such times, the use of organisational tools increases to facilitate communication among bigger teams in remote workplaces, replacing face-to-face conversation. This means that a change in organisation communication should also be reflected in the system’s communications.
Transition to WebApp
As our internal communications became more complex, our core system had more workload to manage. As the company was adding services and scaling up, we made a decision to move from a monolithic structure to more liquid frontend development.
Today, “monolith” has become somewhat of a swear word, whether it’s built by purpose or by accident.
Problems arise when the web user experience comes in contact with internal communications, which, ideally, shouldn’t happen. We solved this by creating a separate WebApp, where the frontend of the app communicates with the b
Backend for Frontend (BFF), that in turn communicates with the API in the core system. The first phase of architectural transition took six months and two live attempts to reach the current functionality that makes sure the user experience is no longer coming in direct contact with the core system.
Mintos needed a solution for the main system integration, core system and migrating screens, but that meant moving only the screens available for unauthorized users.
The game plan was to start simple, iterate quickly and gather the monitoring data of the running system in production.
The great thing about the transition is that it didn’t need a full rewrite of the core system and it could be accomplished incrementally. The transition to a separate web application allowed the team to experiment with the user interface and user experience more rapidly. This resulted in a significant reduction in time to market for many new and redesigned features. After the transition, the third-party solutions could be plugged directly into the backend, without interfering with the core system.
Overall, this process was a small step that brought invaluable learning experience for the team. The second time around the team would definitely put more emphasis on monitoring from the start and track metrics as soon as possible. A new tech stack inevitably comes with a learning curve — meaning the transparent and often communication about the changes is a must-have!