CODEWITHSUNDEEP
domain-driven-designmicroservices
Slohrsh
Slohrsh

Reputation: 785

How to share common Data over several Microservices

I'm writing a Bachelors-Thesis about Microservices.

I'm trying to split a monolith into Microservices and now I ran into a problem that there are some tables in a Database, that are relevant for more than one Microservice. There is no chance to split this data into domain specific views.

My approach is that I will create a new Database Schema with that specific tables and let all Microservices read from it. That would be a shared kernel approach which is not recommended by the experts of Microservices.

Do you have any experience or recommendations about this problem?

Do you have any recommendations about books which are about similar problems?

Upvotes: 3

Views: 1505

Answers (3)

Ivan
Ivan

Reputation: 41

you can create a single microservice for manage this common data ( for example: country or regions data etc.. ) and replicate tables between all microservices.

This microservice was the single point of management this data ( with CRUD ). On Create, Update or Delete operation you synchronize all microservices with Async communication (kafka, rabbitMQ)

With this solution all microservices was independent from each other, and was synchronized with data without http call for best speed performance.

Upvotes: 0

Kyle Smith
Kyle Smith

Reputation: 2332

The general approach is to replicate this data. Each microservice has a copy of the data it needs to it's job well. If you're thinking this makes your solution more complicated, you're right, that is the tradeoff to get the benefits of independently releasable, isolated services.

Something else to consider is that if you have N microservices that need more than references to the same bits of data, it's likely you'd be best served keeping those use cases together in a single service, rather than breaking it up. Fred George has a good talk about watching out for simply trying to split your microservices into 'entity services':

https://www.youtube.com/watch?v=vs_XiP5Lkgg

I would suggest not allowing more than one independently deployed service to read and write the same data, because you will end up with a coupling preventing e.g. schema migrations of that data without potential risks.

Upvotes: 2

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57194

You should be familiar with Pat Helland's paper Immutability Changes Everything.

You should also review Udi Dahan's Data Duplication and Replication, but read with care: Udi's service language is careful to distinguish physical boundaries from logical boundaries. Make sure you are clear on which he is describing at any given time.

Upvotes: 0

Related Questions