Full disclosure I work at MSFT and on the fluid framework.

If you are interested in this you may also be interested in the fluid framework, https://github.com/microsoft/FluidFramework

We use websockets and solve a lot of the state management problem called out here by keeping very little state on the server itself. The primary thing on server is a monotonically increasing integer we use to stamp messages, this gives us total order broadcast which we then build upon: https://en.m.wikipedia.org/wiki/Atomic_broadcast

Here are some code pointers if you want to take a look:

The map package is a decent place to look for how we leverage total order broadcast to keep clients in sync in our distributed data structures: https://github.com/microsoft/FluidFramework/blob/main/packag...

The deltamanger in the container-loader package is where we manage the websocket. It also hits storage to give the rest of the system a continuous, ordered stream of events:

https://github.com/microsoft/FluidFramework/blob/main/packag...

The main server logic is in the Alfred and Deli lambdas. Alfred sits on the socket and dumps message into Kafka. Deli sits on the Kafka queue, stamps messages, the puts them on another queue for Alfred’s to broadcast: https://github.com/microsoft/FluidFramework/tree/main/server...