What Is a Modular Monolith?

In recent years, we have seen a significant increase in apps built using a microservices architecture. We selected this approach mainly because small teams work in isolation without tripping over each other. Yet, this is an organizational problem, not a technical one. We can also build each service using different technologies and scale independently.

With the microservice approach, we have a few disadvantages, too. The system is becoming complex in maintaining and diagnosing issues (logging and tracing). This is very important when dealing with microservices. Yet, we also saw something called “microservice bloatware,” even on Twitter:

But there are many more examples of failures of the microservices approach; if you’re not solving a problem at Netflix size, you probably don’t need microservices.

On the other hand, we have monoliths with a lot of lousy wording about them. But building monoliths doesn’t mean something better per se. In the last few years, we have often seen the identification of monoliths with big balls of mud architecture or purely building legacy code, which doesn't mean to be. Yes, monoliths cannot scale or release independent pieces of the system separately, but those are mainly the most significant downsides. Still, you can create tremendous and high-quality code inside. Monolith brings us much less complexity, reduced network calls, more detailed logging, etc. Most subsystems of an entire application or system are stored in the monolith container. It is called self-contained since every system component is housed in a single container.

We can have architected monoliths that will fulfill all our use cases and requested architecture attributes in the system without dealing with the complexity of microservice architecture. The best example is Shopify, which has over 3 million lines of code and is one of the giant monoliths in the world. Instead of rewriting its entire monolith as microservices, Shopify chose modularization as the solution, while they served 1.27 million requests per second during Black Friday. However, there are also more examples of monoliths, such as StackOverflow, Basecamp, or Istio. Also, recently, we saw that one team in Amazon (Prime Video) abandoned microservice architecture in favor of monolith.

We want to build a modular monolith by creating separate modules and working on them while maintaining simplicity. An adequately produced modular monolith can be a good step that can be transformed into a microservice solution tomorrow if needed. So, the recommended path is Monolith > apps > services > microservices.

"You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile."
— Martin Fowler

When we want to build a modular monolith, it is crucial to divide the system into manageable modules before assembling them into a monolith for deployment. As all communication between the modules might result in a cross-network call if you decide to break it into services in the future, high cohesion, and low coupling are crucial in this situation. This means that all inter-module communication must be abstracted, asynchronous, or based on messaging for the modules to handle calls that travel across the network in the future.

How can we put such a concept in place? We create separate modules; each has its architecture, and those modules are pulled together into a single API gateway. This allows us to deploy the whole system as a monolith, but it will enable us to pull out separate modules into services if needed in the future.