In our application there is a event emitter (window service A) that emits events on queue. There is a notification service (B) (window service hosted in cloud) that reads these events from queue and based on configured rules, send notifications to loggedin users on web application (C).
We are planning to use signalR between web browser and the web application (C). But confused on setting communication between event emitter (A) and Notification service (B). Initially we are thinking to use SignalR there as well. But there is a catch. If load increases, notification service and web app can scale out (having more than one instance).
Lets say there are 3 notification service instances and 4 webserver instances. Now, how would SignalR works between them. Each web server has to open a signalR channel with every notification engine. But this would lead to issue:
There will be tight coupling between notification service and web application. Whenever a new web instance is added, it has to form connection all available notification instance. And it goes down it has to destroy this connection. Same hold true with notification instance.
So, we are thinking of using some pubsub rather than signalR. Right now we can think of Redis pubsub. Notification services will push message to Redis and all the web servers will be subscribing to it and will eventually get message.
Please share your thoughts if we can design it better.
