Transacting monolith to microservice

Transacting monolith to microservice

10th November, 2021

Developing applications in the monolithic style may seem like you’ve gone back in space and time or something that people would term being stuck in the sphere of architectural evolution.  Transferring from monolithic to micro service architecture is important to keep up with the recent trends. 

Monolith means packed in one piece, here in our context. In a monolithic application, the program is built as a single unit, and this makes it too large and complex. It becomes tedious when errors come up, and so making changes becomes a problem. And, next to impossible to do Continuous Integration and Continuous Deployment.

The typical components of a monolithic application are combined into a single platform:

  • Authorization
  • Presentation layer
  • Business logic
  • Database layer
  • Application Integration
  • Notification Module

The reason why monolithic applications are built is because it is quite simple to develop and deploy. In spite of the different components and modules, developers find that the initial part of the project is easy in Monolithic Architecture. They do the UI testing with Selenium.  A monolithic application is easy to scale horizontally, and it is possible to run multiple copies behind a load balancer. 

However, the multiple drawbacks to having a monolithic architecture makes it pertinent that you should start switching to Microservices Architecture. Let’s have a quick run-through of the monolithic application:

Maintenance – It is not easy to maintain or make changes to a large and complex application.

Deploying – With each update, you will have to redeploy the entire application

Startup time – When the application is too large, this slows startup time.

Bugs – The entire application will not function properly when there is a bug. This is because all the instances of the application are identical and so the entire application will be affected. 

New and advanced technologies – The developer might find the initial stages of the application easy, but as they move onto the advanced stages, the entire process becomes cost and time consuming. 

Scalability – Scalability becomes a nightmare because of conflicting resource requirements.


[Image Courtesy: NORDIC APIS]

Shifting to Microservices Architecture

Microservices Architecture

Microservices Architecture is an approach where an application is built as a modular service. Each of these modules serves a specific business goal and there will be an interface through which it will communicate with other services. 

The principle of loose coupling is applied in Microservices architecture, so the dependencies between services and their consumers are minimized. And quite like monolithic services, there will be no change in the application’s performance when changes are implemented and the systems are modified. This is because each of the micro services have their own database, and the services can use a database suitable to their needs.

Here are the main services needed for a typical online service application

  • Authorization Service
  • Order Service
  • Catalog Service
  • Cart Service
  • Payment Service
  • Shipping Service 

Benefits of Using Microservices Architecture

  • Microservices ensure continuous delivery and deployment of complex applications however big
  • Each microservice is small and easy to manage
  • The IDE is faster facilitating productive development in the shortest time
  • Testing is easy because there are small services and they are faster to test
  • Each of the services are deployed independently 

It is easy to share the project among multiple teams, and each team will manage one or more services. They can focus on the service, develop, deploy and scale them independently too

Isolate the problem, so if there is one problem with the application, the other services will not be affected, whereas in a monolithic architecture, the entire system will shut down

No long-term commitment to a technology stack. When a new service is created, the developers can use a different tech stack. Or they can rewrite an existing service using a tech stack. 

Disadvantages of using Microservices Architecture

Well, everything has a dark side, so before mentioning the transacting process, it is important to check out the cons of Microservices Architecture too.

  • Distributed systems complexity is there. Creating distributed systems is not an easy task.
  • Testing is not easy, testing in Monolith is easier
  • Developers have to create an inter-service communication mechanism. And there should be careful coordination and management while implementing use cases that cover multiple services. 
  • There is deployment complexity because there is this operational complexity of deploying and managing several service types. 
  • In spite of the disadvantages, moving from monolith to microservices is a very important and valuable business tactic. 

Automation in Microservices

As mentioned earlier, there will be a number of smaller components in micro services, and it is important that they be automated in every activity including builds, deployment and testing. With CI/CD servers this can be automated, leading to faster production release cycles. Tools like Selenium, Cucumber etc are available for the automation of UI testing . Back end testing process through Junit test cases.

Moving from Monolithic to Microservices

All well-designed monolithic applications will project a separate UI layer from the Service layer, and this will be helpful during transformation. If there is no separation, then the first step would be to separate the UI layer from the service layer, and project them in respective containers. Moving forward to the next step would be an API on the backend so the components can communicate with the backend or the service layer. 

Now comes the next level of transformation. Here there will be a full separation, down the database level.  To make things easier, you can start with decomposing a domain that’s small. This will be easier to extract, and with little risk. 

As the next step, the UI layer specific to the microservice is separated.

Transaction Management

The transaction management itself happens in different stages, and it could be a complex thing. There are several aspects in transaction management like service availability, consistency between services, isolations and rollbacks that must be considered. 

Microservices are meant to be independent, so they can address the business problems on their own. 

API composition

With an API composer, data is extracted from multiple microservices. 

Two-phase commit protocol

This is a mechanism for implementing distributed transactions across other software components. 

In a distributed transaction, you have the transaction coordinator, while the transaction happens in two steps:

The preparatory phase and the Commit or Rollback phase

The Preparatory phase – In this phase, all the participants will be ready to commit to the transaction, and notify the coordinator.

The Commit or Rollback phase – In this phase, either a commit or rollback will happen when the transaction coordinator issues the command. 

The Distributed Saga pattern

The distributed saga pattern is the next stage, it is the solution to undo the changes that happen when a business rule is violated in a local transaction failure. A saga is s series of local transactions. Each time the local transaction updates the database, it publishes a message to trigger the next in line local transaction in the saga. 

Event-driven choreography

Each service listens to the other services and comes to a conclusion whether an action has to take place or not. Each service happens right after the other in a series, and in case of failure, there will be a rollback. 

In choreography, each part of the system will know what it has to do and the process goes smoothly with each part knowing when and what it has to do. There is also another style known as the orchestration, where there will be a central brain guiding and driving the process, just like there will be a conductor in an orchestra. 



[Image Courtesy : ResearchGate.NET]


It is important that Transaction Management be handled efficiently

Transaction Management does take its toll because when you have a number of different micro services, they will have their own independent business capability that connects to different databases. All the steps are to be completed logically or there will have to be a rollback. If there are multiple failure points, the challenges are high.

However, roll back is costly, and developers have to do another transaction or operation to compensate for the failure. The RollBack is the Compensating Transacting Phase to achieve eventual consistency. 


A monolithic architecture would be good for lightweight applications. It is also recommended to adopt the Monolithic approach first, and then shift to the Microservices architecture at a later stage when the needs/requirements change. 

However Microservices can break your large application into different domains, so there will be a separation of responsibilities. It will not impact the work on other services. So as the application scales, you will need micro services. Big organizations like Uber, Netflix followed this procedure from Monolith to Microservices. 

If you are ready to shift from Monolith to Microservices, make sure you get the right partner who can explain the process in detail so you will know how to go about it smoothly. 

Recent Posts

  • August 11, 2023
  • August 2, 2023
  • June 14, 2023

Talk to Our Team for Expert Opinion.

Scalan Labs is a full-service product engineering company that provides dedicated teams for full stack development. We have the top1% talent for product engineering and dedicated teams to help you reach your business goals. Contact us today to learn more about how we can help you!

Click on a star to rate this article...

Thanks for rating this article.

To stay updated, please follow us on LinkedIn!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?