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:

Some disadvantages of a Monolithic Architecture

When should I use Monolithic Architecture?

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

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:

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:

When should I use a Microservices Architecture?

A Microservices architecture can be handy in many scenarios as:


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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Henrique Siebert Domareski

I've been working with software development with .NET since 2011, and love programming and solve problems using clean code particles.