I have a medium scale e-commerce application. Over a period of time our monolithic project got quite heavy in terms of code base. I was exploring the solutions for it and found micro-services is one option but found it like a very early optimization which involves too many risks and increased development cycles. So, I thought of splitting the monolithic app into multiple apps based on business. I come up with following three:
- Storefront (Website)
- Admin Backend (CRM, Reporting etc.)
- Seller Platform
By creating these 3 separate projects, I find following benefits from this:
- They we can independently developed them and wherever a common code base is required, we can add them as library in current projects. B
- These applications can be deployed independently.
- Wherever we need to communicate between applications, we can write limited APIs to transfer data
- Having common database will enable us to keep complete consistency of data by retention of all foreign keys
Having said so, I am concerned about following points:
- Firstly, is this a right approach? Are there any caveats in it?
- Will having a common database accessed by three apps and writing on similar tables will cause any issue later on with scale?
Best Answer
Microservices have their own set of challenges. What you are describing is essentially using the Strangler Pattern to replace the old application. This gives you some benefits:
However, it does have some limitations:
So, I would say it's an effective way to split the complexity of the changes you need to do. The question is whether you understand where your current bottlenecks are for your application.
If you are nowhere near the limits of your current database architecture, then I would power on with your approach as the initial cut. It allows you to focus on the complexity of getting your microservice infrastructure working together without worrying about how data is stored. You can leverage a lot of existing code that handles the database interaction.
That buys you time to consider what changes you need to make.
In short it doesn't have to be perfect right off the bat. It just needs to be good enough to focus on what the next biggest problem is. And know that microservices bring with it a complexity you won't have in a monolithic application. However, they solve a problem that monolithic apps don't have--one of serving customers at internet scale.