5

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?

Apurv
  • 315
  • 5
  • 14
  • It will definitely break Monolithic applications advantages. Your application would be Inflexible, Un-scalable and more tightly coupled with each other, batter you should use external AWS or Azure Queue for good performance. [link](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted) – Ravi Sapariya Feb 04 '19 at 08:56

3 Answers3

5

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.

gvo
  • 845
  • 1
  • 14
  • 22
2

If you wanted to go down this route - I would suggest the better approach would be to shift the focus so you have a central websockets “server” and your microservices connect to that rather than directly to each other. Then you’re essentially replicating how every other architecture does this whether it be RabbitMQ or Kafka etc

Robert Perry
  • 1,906
  • 1
  • 14
  • 14
-3

Apache Pulsar has the ability to work as a message broker and has a WS interface for sending messages to and listening on topics. I haven't tried it myself yet...but I will test to use it for sending and listening on events in different types of microservices. Pulsar in it self is scaleable and allows persistent messaging and can be installed and executed on Kubernetes for example. But I have only read about it...now I must try it myself :).

Ingmar Bengtsson
  • 1