How to share common Data over several Microservices

2
votes

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?

3
domain-driven-designmicroservices
I recommend you also approach the subject from a linguistic and business perspective in addition to a technical, data-first perspective. Why do you need the same concept in two microservices? Do you need all of the data or only facets of it? Is it named the same way in both microservices? Is it really the same concept? I.e. subdomain and Bounded Context modelling. - guillaume31
@guillaume31 I already did the strategic design part of DDD and talked a lot to Developers and Domain Experts. The system, I'm working with, has the purpose to analyze some data and check if everything is ok. Therefore there are distinct use cases. There are a few tables that every use case is analyzing. - Slohrsh
What does your Context Map look like? - guillaume31
There are 4 Bounded Contexts which are dependend through a shared cernel to the common data. My approach is to just let the Bounded Contexts read from a shared database without write permission - Slohrsh
Who has write permission if not the BC's? What kind of common data is that? - guillaume31

3 Answers

2
votes

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.

0
votes

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.

0
votes

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.