CODEWITHSUNDEEP
javaspringspring-mvcwebsocketmicroservices
Apurv
Apurv

Reputation: 365

Can we use Web-Sockets for Communication between Microservices?

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?

Upvotes: 5

Views: 3751

Answers (3)

Robert Perry
Robert Perry

Reputation: 1956

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

Upvotes: 2

Ingmar Bengtsson
Ingmar Bengtsson

Reputation: 1

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 :).

Upvotes: -3

gvo
gvo

Reputation: 855

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.

Upvotes: 5

Related Questions