I’m an unabashed fan of microservices and micro-frontend¹ concepts — no questions. But I think there is a point in the “let’s go back monoliths” movement of the last two years – even if its wording makes little sense to me.

The technology architecture trends follow a repeating pattern. We discovered that the current philosophy has issues, so we invented a new paradigm that fixes the problems of the previous paradigm. People get excited about the latest shiny thing and start bashing everything else as the “old broken thing.” So, when people figure out that the previous pattern was designed for a reason, the counter-movement starts: let’s go to the “old broken thing” because trying to use the latest and shiny for everything causes more problems than it solves.

The Monolith vs. Microservices discussion is a prime example of the phenomenon. While microservices are a fantastic way to solve business problems at scale, they are not a panacea. A distributed computing paradigm will only reduce the complexity of a solution if the source of complexity is a monolith². And moving away from monoliths does not mean we should reimplement all solutions as Microservices.

In the real world, software solutions are a lot like rocks: finding a piece of software resembling a pebble is far more common than discovering a monolith. There is no benefit in distributing or splitting the functionality of the pebble into smaller pebbles.

Thus, the question is not, “Should we go with monolithic or micro-services architecture? It’s “Is our solution complex enough to warrant breaking it into isolated components? And if so, can we defer a bespoke business domain for each?” And learning that your solution is a small, manageable piece of software - does not mean it is a monolith.

When in doubt, I suggest using the following criterion to decide:

1. Is a single team responsible for the solution?
2. Does the solution cater to multiple business domains? For example, a solution that provides event ticket sales and community discussion forums for the same events.
3. Is the solution released in parts, each requiring a separate release pipeline or a publishing schedule?
4. Is the data of the different domains loosely coupled?
5. Do we really care? Is there a policy or an architectural requirement that forces us to use microservices, even when microservices architecture is not the best, or even good solution?

Assuming the solution requires multiple teams to build, and the answer to the rest of the criterion is yes - going microservices is likely the best option. But as you can see from the flowchart below, the alternative for most cases is not a monolith.

So – perhaps we should stop discussing monoliths vs. microservices. And start discussing if the teams have clear goals and boundaries to make these decisions as needed. Because if they do, the rest of the arguments are trivial to solve.