TOP architecture solutions: microservices and monolith. How to choose?

Monolithic architecture: strengths and weaknesses.

The monoliths are conventionally a single code base. All the bases and the application itself will be on the same level and in the same place. Monolithic applications are more accessible to implement and less complex than microservices. The approximate structure of a monolith can be divided into the user interface, data interface, and business layer, and all this is located in one database. It is worth noting that the number of layers in a monolithic archetype can be numerous, but all these layers will be in a single database.

  • Easy to deploy — It’s easy to deploy as a single project. It’s only required to deploy a single application for new feature addition or a bug fixing.
  • Well-known — Almost all developers have had experience with monoliths in one way or another, which means it’s easier to find a potential developer who can implement a project quickly.
  • Easy to debug and test — It’s easy to debug and perform tests in a monolith as all the code is in a single solution. So when you need to debug, it’s only necessary to run the code and debug without doing extra configurations, as well as test performing, you don’t need to configure additional connections between applications. Also, it’s easy to test the UI with some tool like Selenium or to implement end-to-end testing by launching the app.
  • Easy to monitor — When a failure/bug occurs, it’s easier to identify where the problem happened because the code is entirely in a single project.
  • Unavailable time in deploys — When a change or deployment is needed, the entire application becomes inaccessible because of the handling of all the code.
  • It can be challenging to work with big teams — It is difficult to onboard new developers when any feature they work on deals with various code pieces scattered all around the codebase.
  • Tight coupling — it is pretty tricky to get a specific piece of the application out since all the elements of the architecture are closely linked to each other. Plugging out a specific part of code is painful for the whole monolith.
  • Scalability is not flexible — Monoliths can scale, but it’s only possible to scale the entire application. If it receives a lot of requests in only one specific part, you can’t scale just that part, you have to work with the whole app. Also, it’s not always possible to use horizontal scaling; it will be essential to scale vertically, which is generally more expensive.
  • Restrict to the chosen technology — It’s challenging to switch the technologies in a monolith application. It means if you’re designing a monolith, expect to use the same technology stack for the long term.

Microservices: strengths and weaknesses

Microservices architecture is an application divided into small services that are independent of each other. They are technology-agnostic, and each has its own database. This architectural solution has many advantages — nevertheless, it has its own challenges and complexity issues. Furthermore, for successful work with microservices, the development team needs to have more experience and seniority.

  • Deploy independently — It’s possible to deploy only one microservice, as they are loosely coupled (independent of each other). This way, require the whole application to stop working, for a few moments because only a tiny part of the app will be updated/changed.
  • Eliminate the single point of failure — Splitting the application across many small services eliminates the “single point of failure” in the app.
  • Reduces the risk of breaking the app If a microservice fails, it will not affect the rest of the application; it will only affect that single microservice while the other parts of the app will continue working correctly.
  • Minimize downtime when a new version is released — The application will not stop working for a while when a new version of the microservice is released; only the part which uses that specific microservice will be unavailable.
  • Can be easier updated — Since a microservice is not, in general, a big application, it’s easier to change something in the code or even update the framework which is used by the microservice.
  • Easier to work with different teams — When working with many teams, each team can be responsible for a specific microservice or a group of microservices, separating the responsibility of each part of the project between the teams.
  • Easier to understand — A small application is in most of the time, more straightforward to understand than a bigger application.
  • Easier to expand — It’s easy to expand an application by creating new microservices.
  • Independently changeable — When the microservice itself needs to change, this will not affect the other microservices.
  • Can have different databases — It’s possible to choose a separate database for each microservice. A relational database can be the best option in one microservice, and for other microservice, a NoSQL database fits better, which is possible to achieve when working with a microservice. Which database is defined only by the developers.
  • Technology agnostic — Each team can define which technology they want to use in each microservice. So microservice can have different technology; one can be done in .NET, or in Java, another in Node, o in Go, and so on.
  • Agility — With microservices, it’s effortless to add something new and deploy a new version without impacting the whole app.
  • And there is choreography with the single point of failure as a broker which gets all attention.
  • It doesn’t matter wich type of microservices you chose, but it’s necessary to have a team of developers who knows how the system should work; or an excellent team leader who will take care of architecture;
  • Many technologies and languages, or many people and areas of expertise — more difficult project rotation.

Choosing application architecture: Corewide way

We recommend specific architecture to our clients based on criteria we’ve defined through our experience

  • When the application is self-sufficient and scales well horizontally and vertically, we chose the monolith
  • When an application combines heterogeneous functionality, it is better to go straight to microservices. Moreover, if the app has the back-end more than in two languages or the app has the big data / API — we also choose the microservices, as applications like this are benefited from atomic components that each do their bit of work
  • If an application needs flexible horizontal scaling — pick microservices as you can scale a separate service. When flexibility is in question, microservices are often the answer.
  • It’s important not to confuse microservices with sidecar services. A multifunctional application with a dozen identical workloads running in parallel performing various tasks is still a monolith — but the kind that cleverly exploits its architecture.
  • An application designed as a monolith often becomes the first microservice — when you decide to separate the new functionality from the existing app codebase instead of including it there. Moreover, monoliths are usually easier to rewrite for microservices from scratch than to remove separate blocks and turn them into services
  • If you are aiming at microservices, you should immediately decide on two things: data handling scheme (orchestration vs. choreography)
  • what functional scope limit — to avoid creating a new service unless its functionality is out of the scope of the existing one.
  • Do my team, or I have good knowledge about the domain?
  • Does the app need flexible scaling and high availability?
  • Does my team have experience working with microservices?



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


Reliable DevOps service provider for startups and SME software engineering teams.