0

We are migrating from a monolith to microservice.

Note : We store the tenant details in master tenant db which is seperate from the application database

As-is:

  1. The app serves multiple tenants and has around 10 sub modules which are tightly bound.

  2. We are splitting the 10 sub modules into 10 different services and planning to use single database for all the sub modules.

  3. There are around 20 tables in a single database without references.

Plans to:

  1. Keep the connection establishment , model , DTO , response classes (all common classes for all modules are placed in a base class)
  2. Add the base class as a dependency module for all the other 10 sub-modules.

I have the following question for which I couldn't get any proper responses while surfing the internet.

1) Is the above `Plan to` a valid approach ?
2) Will each sub-module try to make its own connection ? 
3) How to address the issue of base class becoming huge and is duplicated in all sub-modules ?
4) Will this cause any deadlocks since each service will connect to same db at any given time ?

Thanks in advance.

Improve this question
  • What advantage do you hope to get changing 10 tightly coupled modules to 10 tightly coupled ‘microservices’? In it’s current form, the question is too broad. It reads as if someone said you need microservices, without knowing how or why. – Rik D Oct 25 '20 at 10:38
  • @RikD " It reads as if someone said you need microservices, without knowing how or why" -- yes you are right. only advantage is deployment time reduction , but it has got multiple disadvantages. am just trying to think through the best design which we can fit in for this use case. – Vignesh_A Oct 25 '20 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.