SignalR Scalability: Scaling Real-Time SignalR Applications on Heroku

Summary

Scaling a SignalR application beyond one server requires coordination because each server maintains its own connected-client list. The guide builds a .NET 9.0 chat application, adds the Microsoft.AspNetCore.SignalR.StackExchangeRedis package, and configures Redis as a backplane with a SignalRChat channel prefix and environment-specific connection settings. It deploys the application to Heroku, changes the dyno type to standard-1x, and runs three web dynos; without session affinity, WebSocket startup fails because the connection may be routed to a different dyno. Enabling Heroku’s http-session-affinity feature keeps requests on one dyno, after which both browsers establish stable WebSocket connections and exchange chat messages successfully across the scaled deployment.

Takeaways

1. 1

   A Redis backplane coordinates SignalR messages between servers so clients connected to different instances can receive the same chat updates.

2. 2

   Scaling the Heroku web process to three dynos without session affinity caused WebSocket startup failures because connection requests could reach different dynos.

3. 3

   After enabling http-session-affinity, both browsers maintained stable WebSocket connections and exchanged real-time messages successfully across the multi-dyno deployment.