Websocket app into stateless microservice?

Question

i would like to convert an app i have created into a proper microservice, following all the usual practices.

However i am unable to understand how to achieve statelessness and horizontal scaling. This specific app does the following in short.

1. User A starts a sharing room and connects to a websocket

2. User B joins the sharing room and connects to a websocket

3. When a third service streams some binary data via tcp to this service, both users get the data via websockets

Think of it as video streaming to a group of people

I am trying to understand how i would manage enforcing the users to connect to the same instance, where the sharing room exists in memory, and how this could possibly become stateless.

One of my issues is that when User B makes the request to join this room, how will I know which instance holds this in memory?

Thank you

Answer 1

You may want to consider a "routing service" - which will keep a mapping between rooms and servers where these rooms are.

Alternatively, you may consider decoupling websocket connection handlers and rooms. So you have one service to server websockers. Another service service takes care of rooms. And one more to map users to websockets.

So when a user joins a room, two things will happen: websocket will be handled in Connection service and the user get a mapping between their id and the connection service instance (this does not have to be a specific instance as this will leak service implementation details; more on this below). In addition, Rooms service will register the user to the room.

Now when there is a message to deliver to all; each user id can be resolved to a connection handler and the message be sent there.

Connection service could have API like: deliver(address, message). Address is something meaningful to the connection service; for example encoded address of the web server and, maybe, a websocket id. This api is nice at it reduces scope for the connection service - all the service knows is how to deliver a message; service does not know anything about users or rooms.

Long story short, you could define services for managing connections, managing rooms and managing users - and let them talk via apis. The main goal is to reduce scope of each service to its core goals.