C
C
Crunchor2020-08-21 16:58:26
Java
Crunchor, 2020-08-21 16:58:26

How to share the database between microservices?

Help with microservice architecture.
At the moment there are 3 different programs.
The 1st program receives the data and writes the same data to DB#1 and DB#2.
The 2nd program executes its logic from DB#1.
The 3rd program executes its logic from DB#2.

The 2nd and 3rd programs sometimes communicate with each other, supplementing their tables.

All 3 programs are written in different languages.

Now I want to translate all this in Java into microservices. In my vision, all these programs would fit into at least 3 microservices. But the important essence of microservices is to minimize dependencies, including providing each microservice with its own database. There is no point in duplicating data for each microservice.
How to be in such a situation?
Do microservices with a "star" architecture (in the center of the database, and microservices in a circle) have the right to life?

By and large, all 3 programs do one big job, each at its own level.
Help me find a solution to this architectural problem.

Answer the question

In order to leave comments, you need to log in

4 answer(s)
S
Sergey Gornostaev, 2020-08-21
@Crunkor

But the important essence of microservices is to minimize dependencies, including providing each microservice with its own database.

Exactly.
There is no point in duplicating data for each microservice.

In a microservice architecture, duplication just makes sense.
Maybe you just don't need microservices, what problem does the microservice architecture solve for your project? Or maybe you, on the contrary, bother in vain about duplication, what problems do you have with it?

R
Robur, 2020-08-22
@Robur

But the important essence of microservices is to minimize dependencies, including providing each microservice with its own database. There is no point in duplicating data for each microservice.

that's it. Therefore, each microservice works with its own data. And he is also responsible for them and no one else.
If your data is duplicated, then this is a big reason to think.
If you need to do something with some data for which microservice A is responsible in microservice B, then you should not duplicate them in B, but change A so that it provides an api for working with this data, and call this api from B. Next And he will do what needs to be done.
Of course, for proper separation, it will be necessary to revise the architecture, data structure, work logic, and so on. But you kind of just want to do this and not just "rewrite in java"

S
SirotaKazansky, 2020-08-22
@SirotaKazansky

I don’t really understand why so many network transactions are needed (they wrote to one database, wrote to the second database, exchanged data and wrote to their own databases), and why make the data access layer a separate service, as suggested here - how will this help?
I think it is worth being guided by business logic when dividing into services. And it’s worth considering what problem we eliminate and what we create when we separate the service into a separate one, again based on the business - can these services live without each other, maybe you have one transaction going through 2 and 3 programs sequentially, and it makes no sense if something fell - you need to roll back then the states. Think about what will happen if the data between the database is out of sync, whether it is important for them to be synchronous. What data volumes, what speed requirements, etc. etc.
I think that at the level of "there are programs, there is a base, they do something" - it is impossible to determine the necessity and correctness of the division.

V
Vladimir Korotenko, 2020-08-22
@firedragon

Any weirdo who says that your business will benefit from microservices is lying!
Based on this postulate, you can start talking:
Advantages of a "monolith" with a base inside a star
1. You reuse the database, which by the way is the most difficult thing for anyone
2. You balance the load without any problems *
3. You will skip the interaction and all sorts of DEVops
Cons
1. you keep the whole database structure in your head (it’s difficult, but how did you manage it?)
2. you don’t need to go through http (s) for data (or this is not a minus)
3. you don’t need to set up claims and other https (you have everything from boxes) Damn, is this exactly a minus?
4. You have one binary (and what kind of guru are you after that?)

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question