CODEWITHSUNDEEP
microservices
user1578872
user1578872

Reputation: 9018

Monolithic to Microservice

I have a monolothic application which I am trying to convert to micro service based apps.

Approach 1:-

  1. Database still remain same, but there will be multiple micro services connecting to the same db

Approach 2:-

Different micro service for different module and each micro service will have its own database. But, each module need user data( Table -> user).

Say, We are breaking into 4 modules. Admin module, Billing module, Appointment module, Inventory module

Here, For Ex:- Admin module, Appointment module & Billing module needs user data. For appointment module, certain appointment queries needs to be joined with user table which is there in other DB.

How to go with this?

Upvotes: 2

Views: 198

Answers (2)

xs2tarunkukreja
xs2tarunkukreja

Reputation: 462

Microservice should never have common database. We should avoid the same.

Now 2nd option is appearing more near to microservice. But it have one drawback that is sharing user DB. Ideally user DB should be manage by a separate service (main source of truth for user data).

Now question comes, how other services will get user data. There are 2 options :- A. Other service will call User service to get user data. B. Other service will keep replica of user data. Whenever there is any change in user data in user service, it will publish an event and all other service will update replicate the same.

Now question come which option you should pick. I prefer A option (call user service for user data). If there is performance constraint and the same can't be satisfied with use of cache something then you should go with option B.

Upvotes: 3

JArgente
JArgente

Reputation: 2297

First of all, you should consider if you really need a microservices architecture, because you are only going to get the benefits of this type of architecture if the microservices are very independent, I mean if there are very few connections between them.

Said this, the first approach is totally inadvisable, because the key of a microservices architecture is that the microservices should be totally decoupled and if they share the same database + schemas + tables the changes needed for one of them are going to trigger changes for the rest, so you are going to have a distributed monolith (that have the worst of both worlds).

There are two possible solutions. One of them is to call the user service every time you need user information, the bad part of it is that every time you need that information you will have to make a call so you are depending on the other service and the latency will grow.

The other solution is to replicate the user table (only the part needed) on the other services that need this information and update it asynchronously using messages, For example, having a kafka or some other message queue and when there is any update on the users table the user service will publish a message in a specific topic and the other services will be subscribed to it, so they can update their user information accordingly.

The problem here is the eventual consistency, I mean, the updates will not be immediately visible for the other services.

As you can see, the two options have some drawbacks and both of them are because the communication between services, so the fewer communication between them the best for a microservices architecture

Upvotes: 2

Related Questions