[SURVEY RESULTS] The 2024 edition of State of Software Modernization market report is published!
GET IT here

Don't Believe the Hype: Sometimes a Monolith Is Better Than Microservices [Case Study]

Last updated on
February 12, 2024


Monolith vs microservices

The decision between microservices and monolithic architecture greatly impacts complexity and development speed. Microservices offer scalability but come with complexities and longer kickoff times. Monolithic architecture is simpler and suits smaller projects.

Modular monolith

For a project managing assignments and leaves, a modular monolithic approach was chosen due to the project's scope. It allowed logical module separation and potential future transition to microservices. This approach prioritized milestone delivery over configuration. Projects should consider their needs and start with a modular monolithic approach if they might transition to microservices later.

Read on to discover the details.


Don't Believe the Hype: Sometimes a Monolith Is Better Than Microservices [Case Study]

Microservices can result in higher complexity and slower development 

The backend architecture is a make-or-break decision for any project. Making the wrong choice about using microservice can lead to:

  • need for more complex hosting configuration
  • added complexity in the deployment process
  • slower development cycles
  • product performance issues and bottlenecks.

When deciding on the architecture, you need to take into account factors such as domain complexity, team structure, CI and production environments, traffic expectations, and scaling.

When creating a product intended to display people’s assignments to projects, their availability, and leaves, we saw a clear division between modules that could be extracted:

  • Leave management
  • Assignments
  • Projects
  • User info and time availability
  • Authorization

Having logically separated parts of the domain, full control over the environment, and using the newest version of .NET, it was tempting to implement modules mentioned above as microservices. There were definitely some valid reasons to do so. However, we decided to start with a monolithic approach instead, which proved more efficient and allowed us to focus on feature development and fast delivery.

Microservices excel in scalability, but Monolith makes small projects swift

When considering the monolithic and microservices approach, we analyzed the most significant characteristics of both:

<span class="colorbox1"><h3>Monolith</h3><h4>Pros:</h4><ul><li>easier to start a smaller project</li><li>simple client (React app)</li><li>server (.NET backend) infrastructure</li></ul><h4>Cons:</h4><ul><li>single, bigger deployment</li><li>limited scaling possibilities</li></ul></span>

<span class="colorbox1"><h3>Microservices</h3><h4>Pros:</h4><ul><li>independent deployments</li><li>better scaling possibility</li></ul><h4>Cons:</h4><ul><li>project kickoff takes more time</li><li>complexity of the solution and infrastructure</li></ul></span>

Monolith is a more straightforward approach but has its limitations. 

To define which suits your needs, ask yourself two questions:

  1. Will your product benefit from independent deployments?
  2. Do you expect exponential growth and need high scalability?

If you answered YES twice, choose microservice-based architecture. Monolith may slow you down. 

Our own answers were as follows:

  1. Will your product benefit from independent deployments? NO — it’s a small application and faster, modular deployments would not justify the infrastructural overhead.
  2. Do you expect exponential growth and need high scalability? NO — the user base will be limited, and the expected traffic will be relatively small.

Modular monolith provides the best of both worlds

Although we made a decision that microservices are not the correct approach for now, this could change in the future. We wanted to be prepared for a potential transition. In such cases, modular monolith architecture might be the best choice.

If the development team implements a monolith so that:

  • modules are logically separated
  • no module is referenced directly (references are made via mediator)
  • external dependencies are hidden behind abstractions

It’s possible to move from a modular monolith architecture to microservices, as shown below.

Modular monolith architecture
Microservices architecture

Modular monolith allowed us to focus on delivering milestones rather than spending time on configuration

In the case of our project, the modular monolith architecture type allowed us to focus on pushing the product to the next phase rather than tweaking and tuning the connections. That said, every project is different, and there’s no universal way of structuring the application. 

Some products, just like ours, might benefit from not splitting the backend into microservices until it’s absolutely certain they’re needed. If you fall into this category, start with a modular monolithic approach so that it’s easy to pivot when the decision is made to move to microservices-based architecture.

Frequently Asked Questions

No items found.

Our promise

Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.


Tomasz Depta
.NET Software Engineer

Full-stack .NET engineer with 9 years of professional experience. Microsoft certified, graduate of The Silesian University of Technology.

Jacek Kwapuliński
.NET Software Engineer

Full-stack .NET engineer with 13 years of professional experience. Microsoft certified, graduate of The Silesian University of Technology.

Read next

No items found...

Get smarter in engineering and leadership in less than 60 seconds.

Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.