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 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.