I'm designing an application using Micro-Services and I'm unsure on the best mechanism to use to collect data from multiple services.
I believe there are two options:
- Integrate an 'inter-service' communication mechanism that allows the services to talk directly. The API Gateway would call an individual service, which then calls other services to collect data, before returning the consolidated response to the API Gateway. The API then returns the response to the caller. (This would have to be synchronous calls when the call to serviceB requires the response from serviceA. I.E Separate Person and Address Services.)
- Have the API Gateway call each service directly and consolidate the data within the API before returning the response.
I'm leaning towards the second option, as having the services talk to each other would introduce coupling, in which case I might as well just architect a monolithic application. However, there are a few serious drawbacks that I can think of off the top of my head with this option:
-
Having the API executes multiple calls to multiple services increases the load on the API server, especially when some of those calls are blocking.
-
This method would mean the API has to be aware of what the application is trying to do (I.E Logic would have to be programmed into the API to handle calling the services in turn, and then to consolidate the data), rather than just act as a dumb 'endpoint' for the micro-services.
I'd like to know what the standard approach to this problem is and if there is another third option that I'm missing?
Best Answer
I would generally advise against having microservices do synchronous communication with each other, the big issue is coupling, it means the services are now coupled to each other, if one of them fails the second is now fully or partially disfunctional.
I would make a clear distinction between state changing operations and read operations (CQS Command Query Separation). For state changing operations i would use some kind of messaging infrastructure and go for fire and forget. For queries you would use Synchronous request response communication and could use an http API or just go directly to your data store.
If you are using messaging then you can also look at publish subscribe for raising events between services.
Another point to consider is (transactional) data sharing (as opposed to read only views) if you expose your internal state the reader might get the wrong state of your data, or the wrong version, and also will potentially lock your data?
Last but not least, try to do everything you can to keep your services autonomous (at least at the logical level).
Hope this makes sense.