We have a use case where we have two microservices, Microservice A pushes a long-running task to Microservice B.
Microservice B starts processing the task and keeps updating the status of the task. Now Microservice A has to constantly poll Microservice Bfor an update on the status of the task.
We don't have queues in our current setup.
So, We thought of creating a web socket between Microservice A and Microservice B so that Microservice B can push the status updates to Microservice A. Would this design violate any of the principles of Web sockets and also will it be a better approach compared to constant polling?
The most recommended option would be to add a queue :
- That would reduce the coupling between microservice A and microservice B
- That would allow Microservice C which will also be interested in the task status/result to be aware of it without any change for Microservices B
If you still go for websocket, you would have to consider cases of scalability (what if you have two instances of MicroserviceB, which one to call), failures (what if one service fails, who re-runs the socket...), and a few others. That's why it's not the best option to do asynchronous calls in a Microservices environnement.