I am breaking a monstrously large monolithic enterprise application into several microservices and have identified business capabilities around which the services will be modeled. The application has different modules (HRMS, Transaction Management, etc.) interacting with each other. I do not have the requirement of catering to disparate devices.
There are certain request-(immediate)response use cases for which communication between microservices via an API Gateway seems apt. However, for many features, a response is not (immediately) required and publishing an event (e.g., 'EmployeeCreated') to a message broker (RabbitMQ) seems more appropriate.
My aim is to use asynchronous pub-sub as much as possible, and keep the API Gateway simple and dumb to avoid having another monolithic and single point of failure.
I have the following question(s):
i) Is it a good approach to have some features implemented by inter-microservice communication through a RESTful API-Gateway, and others via asynchronous pub-sub? Are there any challenges to be mindful of?
ii) Would it be a good option to have a central routing gateway subscribing to message broker events and calling corresponding RESTful APIs? I fear the two giants (central msg broker & API gateway) may defeat the purpose of MSA in the first place.
iii) If I am to use (i), this answer suggests windows services work better with RabbitMQ, and that self-hosted Web APIs in windows services may be a good option. This way, the windows service can consume certain events and expose some APIs for synchronous calling. Is this recommended? Assuming .Net paradigm, do asynchronous microservices necessarily need to be windows services?
Sorry for being broad in scope. Any help is appreciated.