So I am trying to get a grip of microservices. Each service should stand for itself as far as I understood.
In my example I have a Unit.API and a Combat.API. The Unit.API db contains around 1,000,000 different units.
Now if I want to calculate / create a combatLog in the Combat.API, I somehow need to know which user used which units.
approach 0: wrong approach as far as I understood:
In the post method of the controller I get all the unitIds as parameters and then I make a call to the Unit.API to get the units.
approach 1: correct approach?:
I have a duplicate of every unit from Unit.API in my Combat.API. In the post method of the controller I get all the unitIds as parameters and get the combatUnit "copies" from the Combat.API db. Whenever a unit changes I have to send an event from Unit.API to Combat.API to make the same change there.
approach 2: also wrong?:
In the post method of the controller I get all the units directly via parameters.
I think approach 1 is actually correct, but for me it feels wrong. There could be thousands of changes to the units each minute and I would have to send thousands of events just to keep the other db updated. What's correct here?
Approach 0: This seems to be the most lightweight solution, but here you will face with kind of "infrastructure coupling". What does it mean? It means, that when Unit.Api will be down or broken, then Combat.Api will not work either as it is dependant on unit service.
Approach 1: This is kind of solution "by the book". You duplicate data, but thanks to that you have independent services.
Approach 2: Looks like workaround for me :)
First of all, you should aim for having independent services, if you are going into microservice architecture. But in some cases, having rich communication between them can be also a bottleneck and hard to maintain.
I have met with different approaches so far, exactly same which you're mentioning. Before you choose the best one, you should think about the risk and complexity and it's more up to you which option you agree on, beeing aware of disadvantages.
Furthermore, I think you should once again take a look on your architecture... I don't know what will be the usage and purpose of Unit.API, but if it is only used by Combat.API, maybe it should be the one microservice / boundedcontext ?