Azure SignalR Service for Real-Time Apps

Azure SignalR Service is a fully managed Platform-as-a-Service (PaaS) that simplifies adding real-time web functionality to applications. Real-time means the server can push content to connected clients instantly without the client polling. The underlying technology is ASP.NET Core SignalR, an open-source library that abstracts WebSockets, Server-Sent Events (SSE), and long polling. However, hosting SignalR yourself requires managing persistent connections, scaling out across multiple servers (backplane), and handling connection drops. Azure SignalR Service removes that burden by acting as a proxy between clients and your application server.

Azure SignalR Service uses a negotiation process to establish a persistent connection. The client first sends an HTTP request to the application server's /negotiate endpoint. The server responds with a URL pointing to the SignalR Service endpoint, including an access token. The client then opens a WebSocket (or fallback transport) directly to the SignalR Service. From that point, all messages between client and server flow through the SignalR Service, which handles routing, broadcasting, and scaling.

The service operates as a message broker. It maintains a mapping of connections (connectionId) to groups and users. When a server wants to send a message, it calls the SignalR Service's REST API or uses the SignalR SDK, and the service delivers the message to the appropriate clients. This decouples the server from direct client connections, allowing the server to scale independently.

To create a SignalR Service instance via Azure CLI:

az signalr create --name mysignalr --resource-group myrg --sku Standard_S1 --unit-count 1 --service-mode Default

The --service-mode can be Default (requires an app server), Serverless (no app server), or Classic (supports both but has limitations).

To get connection strings:

az signalr key list --name mysignalr --resource-group myrg

To test connectivity from a client, use the SignalR CLI tool or a simple JavaScript client. For example, in a browser console:

const connection = new signalR.HubConnectionBuilder()
    .withUrl("https://mysignalr.service.signalr.net/client/?hub=chat")
    .build();
connection.on("ReceiveMessage", (user, message) => console.log(user, message));
connection.start();

A financial services company needs a real-time dashboard showing stock prices, portfolio values, and alerts. The application is an ASP.NET Core web app hosted on Azure App Service. They use Azure SignalR Service to push price updates to thousands of traders. The server receives price feeds from a third-party API and broadcasts updates to all connected clients every second. With SignalR Service, they avoid the complexity of managing WebSocket connections at scale. They configured 10 units to support 10,000 concurrent connections. The system handles 5 million messages per day. The key challenge was authentication: they used Azure AD to authenticate traders and passed the user ID to SignalR Service to ensure only authorized users receive sensitive data. They also implemented private endpoints to keep traffic within their virtual network. Misconfiguration: Initially, they set the service mode to 'Serverless' but still had an app server, causing negotiation failures. They corrected it to 'Default'.

A gaming company uses Azure Functions with SignalR Service in serverless mode to send real-time notifications to players when friends come online or when game invites are sent. The function app processes events from a queue and uses the SignalR output binding to push messages. They chose serverless mode because they have no persistent app server; the function app scales to zero when idle. The service handles 100,000 concurrent players during peak hours. They use groups to manage game rooms: each game has a unique group, and players join the group when they enter the game. When a player makes a move, the function sends the update to the group. The challenge was managing group membership: they had to ensure players leave the group when they disconnect. They implemented a disconnect event handler using the SignalR Service's OnDisconnectedAsync endpoint in a function. Misconfiguration: They forgot to set the HubName property in the function's SignalR attribute, causing messages not to be delivered. They fixed it by specifying the exact hub name (e.g., [SignalR(HubName = "game")]).

A SaaS company provides a collaborative document editor similar to Google Docs. They use Azure SignalR Service to broadcast changes to all collaborators in real-time. Each document is a group. When a user types, the server broadcasts the delta to the group. They use the 'Default' service mode with an ASP.NET Core server that handles conflict resolution. The system supports 50,000 concurrent connections across 50 units. They implemented a custom reconnection policy with exponential backoff to handle network drops gracefully. The biggest issue they faced was message ordering: because SignalR Service does not guarantee order for messages sent from different servers, they had to implement a sequencer on the server side. They also used the AddAzureSignalR overload that allows setting ServerStickyMode to Required to ensure all messages from a client go to the same server. Misconfiguration: They initially set ServerStickyMode to Disabled, causing clients to reconnect to different servers and losing state. They changed it to Required after understanding the mechanism.