Answer the question
In order to leave comments, you need to log in
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
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.
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.
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.
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 questionAsk a Question
731 491 924 answers to any question