I am working on social platform with a distributed architecture. The platform should offer a chat module, but since the most efficient way to implement a chat is using websockets. I am not sure what part of my architecture should have the websockets server.

enter image description here

Basically, I want my system to have an api gateway component that will route all the requests to the appropriate microservice, I will implement this as a simple http server. But when it comes to handling the chat messages, there has to be a websockets server somewhere in my architecture.

Is it a good design decision to have 2 servers in my api gateway: one http server to handle regular http requests and other websockets server to handle chat specific actions (talking with a peer for example)?

Would it be a better design decision to completly decoulpe the websockets server from the api gateway?

  • 2
    My initial reaction is to use the same gateway. The protocol seems irrelevant to me, but I'm curious to know if the persistent connections using web sockets justifies a slight change to the architecture. Just trying to think of the downstream affect it has on the internal microservices. Are they independently deployable and scalable? If something goes sideways with chat, and connections flood the API gateway, do the other microservices suddenly become unavailable? Are you introducing a single point of failure? Sep 27, 2021 at 12:25
  • Related question on StackOverflow: Websockets in microservices architecture. Sep 27, 2021 at 12:28

1 Answer 1


The short answer is - yes. The more complete answer is, yes, but watch out for scalability issues. My advice is anything that requires constant connections (websockets, TCP etc) - split it out of the gateway and call it seperately.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.