Issues with Asychronous Communication
- How should a long-running process on the server be presented to the client? If the server is experiencing a high peak in demand, or if the resources are scarce, chances are the client will be affected too. Should it just wait? Should it timeout? How should the client interpret this situation?
- When an upstream dependency (server A calls server B) is unavailable, should the client care? Why should the client be sensitive to our ecosystem. From its standpoint, it reached the server, the rest is all internals.
- Guaranteed response time: what if I told you that my server will respond in O(1) no matter what. How is that for usability?
- What if the client does not need a response right away? Assume that I place my order in the context of an ecommerce application. I know what I ordered, I know how much I paid and I know when and where I will be delivered. Why should I hang in there until the server does all its housekeeping (updating product stocks, notifying the warehouse, ….)
- Better yet, you don’t know whom you’re talking to but you’re sure that your request will be honored. I always feel this way when I need an administrative paper. It seems that I always need to find the right person, and more importantly, at the right time. I always wished I could just submit my request to a “mailbox” and just head home and be sure that it will be fulfilled.
- My request is more urgent that yours. Now you’re in a nuclear power plant, and maintenance staff keeps track of the major events there by posting these events to the monitoring application, business as usual, cooling check… Suddenly, Mr Hero realizes that a major event that jeopardizes the safety of the whole neighborhood is about to take place, and posts an emergency stop payload, now I wouldn’t like to be the one who processes a ventilation check while making the emergency stop wait.
Source: Microservices: Why Asynchronous Communications? – DZone Microservices