Monolithic & Microservices Architecture

Monolithic and Microservices Architecture are two different approaches that can be used to create an application, and each approach has its pros and cons. In this article I explain the main difference between them, and what are some of the benefits and challenges of each architecture.

Monolithic Architecture

A Monolith is a software application that typically contains all the code in a single code base. When working with .NET Core, for example, the whole application will be inside of a single solution file, and in a monolithic architecture, the application will connect into a single database. This is a very common approach and generally almost all developers when started to code, work in this kind of architecture. A monolith app is easier to implement and is much less complex than a microservices architecture. This is an example of a Monolithic Architecture:

Note that in this architecture you can also have many layers, but it will be everything inside the same solution and this application will connect to a single database.

Some advantages of a Monolithic Architecture are:

  • Simplicity — All the code is in a single solution. If you need to change something, all the code you need is in a single place. If you need to run the app locally, it’s only necessary to run a single application.

Some disadvantages of a Monolithic Architecture

  • Can become too big and difficult to maintain — When the project starts, it’s easy to maintain, but through the years the application can become bigger, and this can be difficult to manage. A monolith application works really well for small or medium applications, but when the application is very big and complex, this can become a problem.

When should I use Monolithic Architecture?

A Monolithic architecture can be very handy in many scenarios as:

  • When you know that the application is not going to be so big

Microservice Architecture

In a microservice architecture, you split the application into small services, and these services are independent of each other (loosely coupled), they are technology agnostic and each one has its own database. This kind of architecture brings a lot of advantages, but also comes with many challenges and complexity. Working with microservices also demands more experience and seniority from the development team.

This is an example of a Microservices Architecture:

As shown in the image above, the UI connects with one or more microservices, and these microservices can communicate with each other by synchronous or asynchronous communication. Also each microservice has it’s own database.

It’s also possible to use an API Gateway, which will handle the requests through the microservices, in this case, the UI will connect to this API Gateway and the API Gateway will handle all the requests between the microservices:

How small a microservice should be?

This is a common question when starting to thinking about microservices. There are no rules saying how big or how small a microservice should be, but in many places, you will find that a microservice should be the size of your Bounded Context, and I totally agree with this mindset.

Some advantages of a Microservice Architecture are:

  • Flexible scaling —Each microservice can be scaled independently of the other services. This way when a part of the application is receiving many requests, for example, it’s possible to scale only the specific microservice, instead of scale the whole application. Microservices are handy in cases where it’s necessary to have high availability of the application.

Disadvantages of Microservice Architecture

Working in a microservice architecture it’s much more complex than working in a monolith application. Of course, a microservices architecture brings a lot of benefits, but also comes with a lot of challenges.

Some challenges of Microservices are:

  • Development productivity — Imagine a scenario where there are ten microservices, and you need to implement a new feature in one of them. In some cases, it’s necessary to execute many of them locally (using some specific version) or make use of an environment where the microservices are deployed for development purpose, to be able to access many parts of the application.

When should I use a Microservices Architecture?

A Microservices architecture can be handy in many scenarios as:

  • When you know that the application will grow a lot and will be really big


Each kind of architecture brings some advantages and some disadvantages, and to choose the right architecture for your project it’s good to take into account the points that were explained. Like it’s said, “there is no silver bullet”, so each approach will bring pros and cons.

To decide which architecture you should use in your project, always try to identity some points making some questions as: The application is going to be big and complex? Do I or my team have good knowledge about the domain? Flex scalability and high availability is a requirement to the app? Does my team have experience working with microservices? It’s important to also take into account the knowledge of the team and the complexity of the system. If you answer yes to most of these questions, probably a Microservice architecture can be a good option for your project. But if you know that the application will not be so big, and you don’t really need to have the app 99% of the time available, and the domain rules are not well defined, or the application is not going to be too big or too complex, or the application is only a simple application, a monolith app can be the best option for you.

A monolithic architecture is simpler and easier to implement, but the project can be a bit difficult to maintain when the application grows too much and more developers are working on the project. A microservices architecture allows you to have smaller and separated applications, allowing you to use different technologies in each microservice, allowing flex scalability and making it easier to work with different teams, but this also brings much more complexity to the project. Being aware of all these points can help you to define which architecture will fit better for your application.

.NET Full-Stack Developer | C# | .NET | .NET CORE | ASP.NET MVC | Unit Test | Angular