The Modulith way

Bronislav Klučka on May 08, 2025

Consider the following applications:

Customer Management System
Content Management System
Invoicing/Accounting Application
Help desk
Task/project management system
Managing store resources

A significant amount of the applications we use or write share many similarities with these applications.

User management, authn, and authz
Business-level entities and their management
Data visualizations across business domains

It's important to understand that different types of applications require different architectural strategies. For example, consider operating systems, games, and AI.

For the applications mentioned at the beginning of this article, however, let's discuss modulith, or modular monolith.

The monolithic style has a bad reputation, but it is useful for smaller applications. The problem is not the monolith itself, but rather how it is written. Frankly, if developers write a monolith as a legacy mess that no one understands, why would they think that making it distributed would actually make it better? The result will be a distributed mess.

So, what is a monolith? Put simply, it is an application built as a single, deployable unit. Technically speaking, many applications - such as web-based and client-server applications - are distributed. Their servers run independently and are deployed independently of the front end (client).

However, when considering just the backend or just the frontend, we can think about a monolith.

Why choose a monolith over a distributed architecture, such as microservices? Networking creates its own set of problems. There are benefits, but also costs.

Let's ask ourselves a few questions.

Will more than one team be working on this application?
Do we need different deployment strategies for different parts of the application?
Do we need to scale different parts of the application differently? For example, do we need to scale one part a hundred times?
Do we need to support hundreds, or thousands, or more of concurrent requests?

If the answer to all of these questions is no, then there is no reason to design microservices. We'll cross that bridge when we come to it.

There's a way to create a well-designed monolith that won't turn into a big ball of mud. It's evolutionarily extensible and ready for situations when you might need to separate a module into its own independent service.

The modulith way.

The problems with choosing a more distributed system (let alone microservices) lie in the questions posed. If you don't know the answers, how can you define the borders of a distributed service? It is easier, faster, and less painful to start with modulith and separate specific parts into distributed services as needed.

You can find modulith structure in another article.