SignalR Backplane

The client will connect with the server using the WebSocket protocol so the client connection will be persistent always until the client or server disconnects. Whenever the number of clients increases then the server also needs to be scaled out horizontally. While scaling the server horizontally we need to broadcast the message to all the clients connected to all the Hub servers. Based on the load balancing technique used on the server side, only one server will broadcast the message so the clients connected with the corresponding server alone will get the message. The remaining clients connected with the rest of the servers will not get messages. We can find this issue whenever we can scale our service in the server farm. Clients will get messages in the round-robin method. We can address this issue using SignalR Backplane.

There are different ways we can address this issue. Each one will have specific use cases.

Azure SignalR Hub Service

Every connection will be persistent, each connection will occupy the corresponding socket port until it's disconnected. Meanwhile, any other request will not be served by that port. It will create a Service Unavailable issue whenever the load is high.

Azure provides the SignalR Hub Service. All the clients connect to azure Hub. Backend we need to push the message to the azure hub with the corresponding group Id or connection Ids list. Azure will manage to deliver the message to the corresponding clients.

Azure will maintain the corresponding connection, and resource usage for those connections based on the plan we have subscribed to. We don't require to maintain the separate infra to manage these connections whenever on high load. We can use this option whenever we are having problems scaling our infra based on the load or the load will be dynamic based on the business needs. We need to analyze the network connectivity between our server and the Hub. The connectivity path between the server in the cloud or on-prem will make a significant impact on message delivery and throughput.

Redis Backplane

We can manage the client connection using Redis. Redis will store these connections and it will send the connection details to Server farm using the pub/sub model. SignalR provides a library to integrate with Redis. We can use any Redis PaaS service in case we are hosting our SignalR services in the Cloud otherwise we can use any OnPrem Redis service itself. A combination of Redis Cloud service and SignalR OnPrem service will create a delay in the notification delivery. In this kind of situation, we can either use OnPrem Redis or we can use SQL Backplane.

SQL Backplane

We can manage the client connection on the Server farm using SQL. SQL will store the connection and it will send the connection details to the Server farm. SignalR provides a library to integrate with SQL. But it has limited to support up to 10K messages per second. We can use this approach whenever we have deployed our service in OnPrem. We can manage all the hub connections as well as message broadcast across all the servers. We need to create a separate database to maintain this backplane. We need to provide the schema and table creation permission on the corresponding database. It will be limited to the environment that will serve up to 10K messages per second.