What Is a Modular Monolith And Why You Should Care? 🔥
Learn more about modular monoliths, their benefits, and the challenges with microservices. (6 min)
Over the last few years, I have managed to work with various software architectures, ranging from monoliths to microservices and their variations.
Each architecture had its own set of unique challenges, problems, and advantages.
And there is one architecture that really stood out—the Modular Monolith architecture.
Modular monoliths blend the simplicity and robustness of traditional monolithic applications with the flexibility and scalability of microservices.
I’d say that modular monoliths bring the best of both worlds.
The modular monolith architecture allows you to work in a unified codebase with clearly defined boundaries and independent modules.
This way, you can have high development velocity without the complexity of distributed systems.
In today’s article, I’ll share more about modular monolith architecture and why you should know about it.
CodeRabbit: Free AI Code Reviews in VS Code - Sponsor
CodeRabbit brings real-time, AI-powered code reviews straight into VS Code, Cursor, and Windsurf. It lets you:
Get contextual feedback on every commit, not just at the PR stage
Catch bugs, security flaws, and performance issues as you code
Apply AI-driven suggestions instantly to implement code changes
Do code reviews in your IDE for free and in your PR for a paid subscription
What is a Modular Monolith?
A modular monolith is a single deployable application that’s internally organized into well-defined and loosely-coupled modules.
The modules are split into logical boundaries, grouping related functionality together.
These modules communicate through well-defined, public APIs, events, or messages, instead of directly calling each other’s functionality.
These approaches promote modularity and separation of concerns, and improve the cohesion of the system.
You can think of modular monoliths as a microservices architecture packaged into one deployment unit.
This way, you get the organizational benefits of the service boundaries without the distributed system overhead.
Even if you want to scale one of the modules due to high traffic or other factors, you can easily extract the module and deploy it independently.
Modular monoliths give you this kind of flexibility.
What is a Modular Architecture?
To design a modular monolith, we must understand what a modular architecture is.
The core principles of modular architecture include:
Separations of Concerns - Each module is independent, handling a specific business domain or business capability.
Loose Coupling - Modules depend on interfaces, not implementations.
High Cohesion - Related functionality stays together within modules.
Explicit Interfaces - Clear contracts define how modules interact.
This means that each module:
Must be independent.
Must provide the required functionality.
Must expose a well-defined interface to other modules.
The end goal is not to have 100% independent modules because this would mean that modules are not integrated together.
The main idea is to have loosely coupled modules and keep the number of dependencies low.
We can use a few techniques to keep the modules independent, like data isolation and linting rules, for example.
If we see that two modules communicate too much with each other, you might have incorrectly defined boundaries.
Then, you could consider merging the two modules together.
Remember:
A module is a grouping of related functionalities together that are accessed through a well-defined interface.
And once you have a modular architecture, you can easily extract modules into separate services.
Start With a Modular Monolith
In recent years, developers have favored the microservices architecture.
Yes, it provides many benefits like better scalability, clear service boundaries, independence, and much more.
But, it does come with a big cost - complexity.
I’d say that most teams and companies would be better off starting with a monolith application.
As Martin Fowler says:
You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.
And even better, consider starting with a modular monolith.
When you’re building a new system, you’re making countless architectural decisions with incomplete information.
You don’t fully understand your users patterns, scaling needs, domain boundaries, etc.
Starting with microservices in these early days will lock you into these often incorrect assumptions.
Even big players like Shopify and Google bet on modular monoliths.
You can read this paper from Google about “Towards Modern Development of Cloud Applications”.
In this paper, Goggle identifies five main challenges with microservices:
Performance - Sending data between services over the network slows everything down, especially when you split your app into too many pieces.
Correctness - Most big failures happen when different versions of services try to talk to each other and mess up.
Management - Have to manage multiple different applications, each with its release schedule.
Frozen APIs - Once you create an API between services, it’s really hard to change it without breaking everything else.
Development Velocity - When you need to make changes across multiple services, you can’t just deploy them all at once - you have to coordinate carefully.
As you see, the cost of starting with microservices is high.
So starting with a modular monolith sounds compelling.
I also recommend reading about the fallacies of distributed computing if you’re unfamiliar with them.
Remember:
You can easily migrate from a modular monolith architecture to a microservices architecture because each module is well defined, isolated, and separated.
Benefits of a Modular Monolith
Modular monoliths have multiple benefits.
Here are the ones I consider the most important:
Simplified deployment - You build, test, and deploy one application instead of multiple services across different environments.
Improved performance - Communication between modules happens through fast in-memory calls, instead of slow network requests.
Enhanced development velocity - You have a single codebase to manage which simplifies the debugging and the overall development process.
Easier transaction management - Managing transactions in a distributed systems is very challenging. With modular monoliths you use a single database and transactions are much simpler.
Lower operational complexity - Modular monoliths reduce the operational overhead that comes with managing and deploying a distributed microservice system.
Easier transition to microservices - Well-defined module boundaries make it straightforward to extract individual services and use microservices.
Monolith vs. Modular Monolith vs. Microservices
The biggest difference between modular monoliths and microservices is how they’re deployed.
Microservices use physical boundaries between services, while modular monoliths use logical boundaries.
With microservices, you have a clear strategy for modularity and structuring bounded contexts.
But, you can achieve this without building a distributed system.
The main problem is when people try to enforce code boundaries using microservices.
Instead, you can build a modular monolith to get almost the same benefits.
Modular monoliths give you high cohesion, low coupling, data encapsulation, focus on business functionalities, and more.
Microservices also give you independent deployments, independent scalability, and the ability to use a different tech stack per service.
You can think of the difference as a well-organized apartment (modular monolith) vs. a neighborhood of separate houses (microservices) - both have clear boundaries, but one is much simpler to maintain.
Choose microservices for the benefits, not because your monolithic codebase is a mess.
— Simon Brown
📌 TL;DR
Modular monoliths offer a compelling way to structure applications.
Modular monoliths offer most of the benefits of microservices without the complexity of distributed systems.
Modular monoliths offer a smooth way to transition to microservices if needed.
The main difference between microservices and modular monoliths is how they are deployed.
Hope this was helpful.
See you next week!
👋 Let’s connect
You can find me on LinkedIn, Twitter(X), Bluesky, or Threads.
I share daily practical tips to level up your skills and become a better engineer.
Thank you for being a great supporter, reader, and for your help in growing to 27.7K+ subscribers this week 🙏
Sounds a lot like an architectural quantum, from the book Software; the hard parts.