In my microservices architecture, I have a bunch of services A, B, C, D etc.
For ex: Service A is responsible for managing students. Service B is responsible for managing assessments, the student take.
Service B stores the studentid in the tables for reference. However when I have to query for all the assessments taken in a given time period, Service B has to call Service A to get the student name. Because the client app wants the name. not the id.
I see a lot of network calls among services because of this. So I was thinking Service A could raise an event whenever a new student is registering. Service B will consume the event and stores student info in its db. (same for student name update as well).
Questions:
Is this a bad practice? What are the pros and cons of this approach?
Feel free to suggest any alternatives.
It is good to allow some data duplication across the services and you can do it many many different ways.
One option is to having Service A publishing an event when a new student is registered.
One alternative (That might be simpler) is that when you create a new assessment against Service B, then you provide the username as part of the CreateAssessment command. In this way you don't need to publish any events between the two services when a new user is created.