I often get a consultation.

Hey, architect. I want to use a microservice to refactor the system, could you help reviewing my architecture design?

This situation is very common, but instead of saying yes right away, I will ask a question.

What problem is your microservice trying to solve?

Guess what, most of the responses were "No, I think this is where microservices should be used."

And, most of the time, I would just say no.

I know that developers like to try new technologies, whether it is new languages, new frameworks or even new architectures, it is easy to try those brand new technologies through a microservice. You can do these new experiments on new business requirements, and I'm open to that. However, when it comes to refactoring, it's not that simple.

As I said in my previous article, the evolution of any system must solve some problems that are currently unsolvable. Please ask yourself a few questions before refactoring your legacy system with microservices.

1. Do you reuse the same code base?
2. Does the microservice share the existed databases?
3. Do you just change the function call in the monolith to an API call through a microservice?
4. Is the same release cycle as the original system?

If the answer to any question is yes, please stop and think carefully, do you really need microservices? Microservices built with these thoughts are just for doing, not refactoring, or even worse.

There are several principles when refactoring a legacy system with microservices.

1. Independent deployments
2. Data isolation
3. Non-overlapping domains

For a huge legacy system, data isolation may not be achieved immediately. Nevertheless, the original system must be strangled by the new microservice in implementing an anticorruption layer.

From the above diagram, in the process of continuous evolution, Legacy should become smaller and smaller, while Modern will become larger, and finally achieve the purpose of replacing Legacy with Modern.

In addition, there is another problem with the data isolation of microservices. How to do when microservices and original systems must maintain data consistency? I've covered distributed transaction before, but are you ready for eventual consistency? This means that has your client identified and handled the eventual consistency correctly?

Changes in software architecture come with pros and cons. From a monolith to a microservice, there will be many benefits.

1. Reduce the problem domain.
2. De-couple the release cycle.
3. Productivity increases by using new techniques without the original big ball of mud.

However, it will also create new problems.

1. Data consistency.
2. Maintain effort increases, especially when the team size remains the same.
3. Performance drops due to more coexistence between the monolith and microservice.

There is no one-size-fit-all solution, we can only make the least worse decision. And with microservices, are you really ready?