Database – Splitting application into multiple but keeping database same

Architecturedatabasemicroservices

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:

  1. Storefront (Website)
  2. Admin Backend (CRM, Reporting etc.)
  3. Seller Platform

By creating these 3 separate projects, I find following benefits from this:

  1. They we can independently developed them and wherever a common code base is required, we can add them as library in current projects. B
  2. These applications can be deployed independently.
  3. Wherever we need to communicate between applications, we can write limited APIs to transfer data
  4. Having common database will enable us to keep complete consistency of data by retention of all foreign keys

enter image description here

Having said so, I am concerned about following points:

  1. Firstly, is this a right approach? Are there any caveats in it?
  2. 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:

  • You focus your efforts on one change so you can get the balance of functionality across your microservices correct
  • You keep the data store working which was working before

However, it does have some limitations:

  • Your bottleneck is now your data store
  • Scaling your application is limited to the database architecture

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.

  • Measure your application so you understand the bottlenecks
  • Use doctrine (all the "rules" for microservices) as a guideline to evolve your architecture
  • Decide what changes are appropriate to address the rate of growth for your system.

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.

Related Topic