Recently, I worked on a project where my team and I had to build a workflow engine. We started without any prior experience building similar systems, and no one in the organization had expertise in this area.
Our first step was studying existing solutions, which proved challenging since we lacked access to source code or detailed documentation explaining the design decisions. We spent three months researching and writing code that we ultimately scrapped 😂 — not my proudest moment.
One major setback was our attempt to implement all features from the start. Instead of beginning with an MVP, we tried tackling all requirements at once. This led to poor architectural decisions that we later had to revise.
Another challenge was the company’s mandate to implement everything as microservices from day one. While this approach might have worked for other projects, it complicated our development process 😂. I’ve always been sceptical of using microservices in initial development since it requires both more developers and deep architectural expertise.
The microservice approach forced us into making unnecessary architectural choices until we pivoted to a modular monolithic architecture. In this setup, each module (service) exists as class libraries or folders, communicating with other modules only through public APIs. This approach allows for natural system growth and provides a reasonable starting point for the team to build upon.
To be clear, using a modular monolith doesn’t contradict microservice architecture—rather, it enhances your application’s ability to grow and scale according to your specific needs.
