Micro Services communication — Synchronous/Asynchronous, Pull/Push or queue based
While everyone understand that micro service based applications has its own set of benefits like scaling individual component, independent development, segregation of responsibility etc, communication among these different micro services brings its own challenges.
While many recommends that component/Micro services should be loosely coupled, and best way to set up communication is asynchronous, queue based event driven system, where one of the micro service publish the event, while consumer micro services process these events from the queue. This Type of communication setup may not be adequate for many scenarios where synchronous response is required for better user experience. Queue based event drive communication does not guarantee on the response time and the delay in processing of the request is expected always, hence cannot be used for cased where response need to be displayed/passed to the end user immediately. Wherever delay can be tolerated, this event based communication gives more reliability and fault tolerance using retries in case consumer goes down or fails to process in one attempt.
Apart for these channel, another difference in the communication way is how the data is fetched for processing. Is the caller need to make the call/push the data or, consumer will pull the data as and when required? This kind of communication again depend on the scenario. For a communication where consumer and producer/provider reliability is at doubt, its good the consumer pull the data as and when required. Whenever consumer us up, it will pull the data. If the provider is down, the pull will fail and consumer will keep retrying. This type of communication can replace Queue based system however delay can be unpredictable if the availability of the applications is too freaky.
Below I am trying to depict few of these user cases and best communication setup between the micro services in the case.
1. Push based Asynchronous model without Queue based system
In a scenario where failure to process any event may not be critical, however caller availability and response time is critical to the workflow and end user, Caller can just make a call to the consumer API and forget about the response. In case of failure/unavailability of the consumer, the call may fail, however The caller will not be impacted. Considering an e-commerce system withan e-email system which send mail for advertising some of the product based on the current order, delivery of email may not be important however the successful current order placement is critical, system will just make a call to the advertisement system providing the details but may not wait for the response.
2. Push based synchronous model without queue based system
Taking a case of same e-commerce system, where billing need to be done in the user preferred currency, the order placement system need to convert the price accordingly. To do so, it makes a call to currency converter service. In this case order placement system need to wait for the currency converter call to give back the response for the order to get placed successfully. Such requirements need a tight coupling of the systems and availability of both caller and provider is needed to successful workflow. If the provider is down, the whole of the workflow need to fail and rollback done for any change. With this type of communication, application should be capable of doing the complete rollback including in various DBs of other micro service which may be part of the workflow. Transaction management in a distributed system is a different topic and maybe I will take it in some other story.
3. Push based Asynchronous mode with queue based system
Considering the same e-commerce system, where each order placement requires an email to be sent to the requester with the order details, while mail is important, a delay can be tolerated but not the failure/fault, a queue based system is appropriate. Queue based system allow caller not to wait for the response, however make sure that request do not fail and consumer will process it with a delay. This also gives an opportunity to the consumer (mail provider in this case) to do a retry in case of failure. Consumer will clear the queue entry only when it is able to run the mailing workflow successfully. Availability of Queue management need to be maintained this case though.
4. Pull based synchronous model without queue system
In the system when a consumer need the data to process the workflow from data producer application, such model can be used. Here caller is a data consumer and make the call to the API which is data producer. This is appropriate when both provide and consumer has availability issues. So whenever consumer is up and running, it can pull the data from the producer instead of producer making the call to push the same. This model can be alternative to the push based asynchronous mode with queue system without queue management requirement. Such model can be used mainly in background jobs and not in normal user workflows. For example, a mailing system keep pulling the recent orders from the order management system to send the mail. In this case, order management system does not need to make a call to mailing system, but mailing system pull the order details and send the mail.
Below is the table explaining what to choose based on the requirement of Communication, and availability mandate requirement to achieve the requirement based on the communication protocol fault tolerance and delay tolerance requirements of the communication.
