keep track of current context of user action using SignalR for push notification

Question

If you look at StackOverflow (SO) site, while you are looking at a specific thread and there is some update to that thread, SO pushes the notification to you. That means SO is aware of user context/user action (which thread you are currently seeing). I am trying to build something similar in my ASP.NET web API application using SignalR.

In order to implement this similar behavior, I am performing following steps.

1. Every time user views a thread, I make a get call to an endpoint to return thread information along with that, I am maintaining a dictionary which I update every time, this endpoint is called. In this dictionary I store the context.connectionId as key and threadId as value (keeping threadId as value since multiple users can view the same thread at the same time).
2. Anytime a change is made to any thread, I ask the dictionary to return me all the connectionId (keys) where value == threadId.
3. Then I push notification to all the coonectionId's returned in step2.

Questions:

1. I feel this is overkill and there might be an easier way to do all this. What is the best approach to handle this scenario?
2. Do you think this approach will scale well and application performance will not be impacted.
3. Tomorrow if I move to server farm, would this approach will still work ?

Answer 1

1. There's nothing wrong with this approach. This seems like a fairly straightforward pubsub approach. A user subscribes to a particular thread upon viewing. The server then publishes updates to that thread to the users who have subbed to it. What you outlined for a context dictionary is really the minimum amount of data needed to send targeted updates to users.
2. Scaling is fine, although I would argue that you should reverse your dictionary for better performance. You should key off the threadId, and keep a list of connectionIds that have subbed to that thread. In doing so, you'd be able to simply add a connectionId to a an existing list when a new user is viewing a thread. You minimize the amount of data you need to keep in memory. As it stands now, you have to loop over every connectionId to figure out what they're looking at and aggregate that into a single list, so you might as well just reverse it and store the list itself.
3. It would work so long as each server in the farm handles their own list of connectionId/threadId maps. If each server can respond to a change in the thread independently, then a farm setup should be fine.