This is where things get separated between monolith and microsrv. In microservices env you cannot keep it DRY. To some degree you will have data duplication.
Say you have a social network. You have 2 microsrv. When someone coments you need to notify the post owner. How you do it?
In most of the case you have the user id, right? The author id. So on the notification service you will do a query with that id to get the rest of the data: email or phone number.
The problem is that data modeling in most of the cases is done all wrong by logical scope not business scope.
It's a phone number or emal, than it should definetly stay on a service called user manager, right? No? Data should be atomic and be store where needed.
But to sync that? Well that is a different story. This is where event driven design comes into place. I will not dive into it because it a topic many people don't like because it's "hard".
I use graph whenever possible and I am happy. No tables just data types. Table border creats confusion. In my app an USER can be called to PHONE NO. and weres size X on CLOTHES, drives CARS. Done, simple and stress free :)
typos
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is where things get separated between monolith and microsrv. In microservices env you cannot keep it DRY. To some degree you will have data duplication.
Say you have a social network. You have 2 microsrv. When someone coments you need to notify the post owner. How you do it?
In most of the case you have the user id, right? The author id. So on the notification service you will do a query with that id to get the rest of the data: email or phone number.
The problem is that data modeling in most of the cases is done all wrong by logical scope not business scope.
It's a phone number or emal, than it should definetly stay on a service called user manager, right? No? Data should be atomic and be store where needed.
But to sync that? Well that is a different story. This is where event driven design comes into place. I will not dive into it because it a topic many people don't like because it's "hard".
I use graph whenever possible and I am happy. No tables just data types. Table border creats confusion. In my app an USER can be called to PHONE NO. and weres size X on CLOTHES, drives CARS. Done, simple and stress free :)
typos