SignalR Redis Backplane — Scaling Real-Time to Multiple Instances

Without backplane (3 instances):
  Instance A: clients 1, 2, 3
  Instance B: clients 4, 5, 6
  Instance C: clients 7, 8, 9

  Doctor on client 1 updates a drug order (Instance A)
  Notification sent to ward group
  Result: clients 2, 3 receive it (also on Instance A)
  Clients 4-9 do NOT receive it (on B and C)

With Redis backplane:
  Instance A receives message → publishes to Redis
  Redis broadcasts to Instances B, C
  All clients on B and C receive the notification
  All 9 clients get the update

// NuGet: Microsoft.AspNetCore.SignalR.StackExchangeRedis
builder.Services.AddSignalR()
    .AddStackExchangeRedis(builder.Configuration.GetConnectionString("Redis")!,
        options =>
        {
            options.Configuration.ChannelPrefix =
                new RedisChannel("SystemForge", RedisChannel.PatternMode.Auto);
            // Prefix namespaces your messages — avoids conflicts with other apps
        });

// appsettings.json
{
  "ConnectionStrings": {
    "Redis": "redis-primary.systemforge.internal:6379,password=secure,ssl=true,abortConnect=false"
  }
}

Sticky Sessions (affinity):
  Load balancer routes the same user to the same instance every time
  Pros: simpler (no backplane), no latency overhead
  Cons: if that instance crashes → user loses connection, must reconnect
        uneven load distribution (one instance handles all connections for a user)
        scale-in removes an instance → disconnects all its clients

Redis Backplane:
  Any instance can receive messages, all instances get them via Redis
  Pros: truly stateless API instances — any instance can serve any client
        instance crash only disconnects that instance's clients (others unaffected)
        proper horizontal scaling
  Cons: Redis adds ~1-2ms per message latency
        Redis becomes a single point of failure (mitigated with Redis cluster)

Recommendation: Redis backplane for any production deployment with 2+ instances

// Configure reconnection and retry for the Redis connection
builder.Services.AddSignalR()
    .AddStackExchangeRedis(options =>
    {
        options.Configuration = new ConfigurationOptions
        {
            EndPoints         = { "redis-primary:6379", "redis-replica:6379" },
            Password          = builder.Configuration["Redis:Password"],
            Ssl               = true,
            AbortOnConnectFail = false,
            ConnectRetry      = 5,
            ReconnectRetryPolicy = new LinearRetry(1000),  // 1s between retries
        };
    });

The Redis backplane handles:
  ✓ Broadcasting messages across instances
  ✓ Group membership is per-instance — groups are NOT shared via Redis

Group membership is NOT shared:
  Client connects to Instance A → joins "ward:4B" group on Instance A
  Client disconnects and reconnects → may connect to Instance B
  → "ward:4B" group on Instance B is empty for this client
  → Client must re-join the group

Solution: clients must re-subscribe to groups after (re)connecting

// Re-subscribe to groups after reconnect
connection.onreconnected(async () => {
    await connection.invoke("SubscribeToWard", currentWardId);
    await connection.invoke("SubscribeToAlerts", subscribedAlertTypes);
});

// Check Redis connectivity as part of health checks
builder.Services.AddHealthChecks()
    .AddRedis(builder.Configuration.GetConnectionString("Redis")!,
        name: "redis-backplane",
        failureStatus: HealthStatus.Degraded,
        tags: ["signalr", "redis"]);

// SignalR-specific health monitoring
app.MapHub<ClinicalDashboardHub>("/hubs/clinical");
app.MapHealthChecks("/health/signalr", new HealthCheckOptions
{
    Predicate = check => check.Tags.Contains("signalr")
});

// Azure SignalR Service handles scaling without managing Redis yourself
// All connections go through Azure's managed service
builder.Services.AddSignalR()
    .AddAzureSignalR(builder.Configuration["AzureSignalR:ConnectionString"]!);

// Advantages:
// ✓ No Redis to manage
// ✓ Handles up to 1 million concurrent connections
// ✓ Built-in high availability
// ✓ Serverless SignalR (Azure Functions)

// Disadvantages:
// ✗ Cost (Azure consumption-based pricing)
// ✗ Vendor lock-in
// ✗ Latency depends on Azure region proximity

# nginx — required settings for WebSocket support with SignalR
upstream api_servers {
    server api1.systemforge.internal:5000;
    server api2.systemforge.internal:5000;
    server api3.systemforge.internal:5000;
    # No sticky sessions needed with Redis backplane
}

server {
    location /hubs/ {
        proxy_pass         http://api_servers;
        proxy_http_version 1.1;

        # Required for WebSocket upgrade
        proxy_set_header   Upgrade    $http_upgrade;
        proxy_set_header   Connection "Upgrade";
        proxy_set_header   Host       $host;

        # Timeout for long-lived connections
        proxy_read_timeout  3600s;
        proxy_send_timeout  3600s;
    }
}