Reputation: 89
Imagine the following:
I have two options:
1) using kafka, for every team inserted on database I send an event and player listen to this event and update its own team table inside player microservice. So, player microservice will have the information about team and player entities in order to make the relationship between them.
We have some drawbacks here about data replication and integrity. Could be avoided using event sourcing and cqrs.
2) Call microservice team in order to list team on view, make the association and post to player microservice.
Drawbacks: calling http the team service could be down.
What is the correct approach to communicate between microservices in order to archive dependency and doing releationship between microservices. Have data replicated on step 1 is reasonable??
Upvotes: 1
Views: 159
Reputation: 1056
I would say that option 1 is favourable. You are then keeping the services decoupled/independent. It also scales, as other future services can then subscribe to the same events.
I don't think data replication is such an issue. I prefer DDD approach whereby individual services control their own data in their own context. Services can then made as simple as they need to be to serve their specific purpose.
Upvotes: 1