Intro

SignalR is ASP.NET Core's real-time communication framework for bidirectional server/client messaging over persistent connections. It is the default choice when the server must push updates immediately (chat, live dashboards, collaborative workflows, notifications) without polling-heavy architectures. A stock trading dashboard, for example, uses SignalR to push price updates to 50,000 concurrent browser clients with sub-100ms delivery — replacing a 5-second polling interval that was generating 10,000 requests/second and still showing stale prices. SignalR hides transport negotiation details behind hubs, but production success still depends on scaling, connection lifecycle handling, and clear authorization boundaries.

How It Works

Mental Model

sequenceDiagram
  participant Client
  participant Hub as Hub runtime
  participant App as App service

  Client->>Hub: Connect and negotiate transport
  Hub->>App: Invoke hub method
  App->>Hub: Publish event/message
  Hub->>Client: Push update

SignalR negotiates the best available transport (WebSockets first, then fallback options). Hub methods are invoked per call on transient hub instances, and outbound messages are routed through Clients.* targets (All, User, Group, etc.).

Example

Hub:

public sealed class ChatHub : Hub
{
    public async Task Send(string message)
    {
        await Clients.All.SendAsync("message", message);
    }
}

Register in ASP.NET Core pipeline:

builder.Services.AddSignalR();

var app = builder.Build();
app.MapHub<ChatHub>("/hubs/chat");
app.Run();

Pitfalls

• Assuming hub instances are stateful leads to lost data because hubs are transient per invocation; keep connection/session state in Context.Items or external stores. In one production incident, a team stored a user's shopping cart in a hub field — every subsequent SendAsync call operated on an empty cart because the hub was a new instance, resulting in 12 hours of lost cart data before the bug was traced.
• Skipping await on SendAsync can drop messages when hub execution completes before send operations finish.
• Treating groups as authorization boundaries is unsafe: groups are routing constructs, not security policy enforcement.
• Multi-node deployments fail unpredictably without a scale-out plan (Azure SignalR Service or backplane) and correct session-affinity assumptions. A 4-node deployment without a backplane delivers messages only to clients connected to the originating node — roughly 75% of connected clients silently miss every broadcast, and the bug only manifests under load when connections distribute across nodes.

Tradeoffs

• SignalR vs polling: SignalR gives lower latency and better network efficiency for frequent updates, while polling is simpler for low-frequency/eventually-consistent scenarios.
• Azure SignalR Service vs self-managed backplane: managed service reduces operational burden and sticky-session complexity, while self-managed options provide more infrastructure control.
• JSON vs MessagePack protocol: JSON is easier to debug and interoperate with, while MessagePack reduces payload size for high-throughput workloads.

Questions

Links

• ASP.NET Core SignalR - Official architecture and transport overview.
• Use hubs in SignalR for ASP.NET Core - Hub lifecycle, targeting APIs, and error handling.
• Scale ASP.NET Core SignalR - Scale-out models, sticky sessions, and hosting constraints.
• Authentication and authorization in SignalR - Auth flows, token handling, and security rules.
• Scaling SignalR at production scale (Ably) - Practical scaling tradeoffs and operational pitfalls.