SignalR connections are server-local. Scale out to multiple instances and messages stop reaching the right clients. Here's how the Redis backplane fixes that - and what you still need to get right.

MilanJovanovic's platform  covers topics related to software development, technology trends, and coding tutorials. Through articles, tutorials, and code examples, MilanJovanovic offers insights into programming languages, development frameworks, and best practices in software engineering. Readers can learn about software design principles, development methodologies, and emerging technologies to enhance their coding skills and build high-quality software applications.

Milan Jovanović

When scaling a SignalR application to multiple instances behind a load balancer, notifications can silently drop because each server only knows about its own connections. The fix is a Redis backplane — a shared pub/sub layer that lets all server instances route messages to any connected client. Setup requires just one method call: chaining `.AddStackExchangeRedis()` onto `AddSignalR()`. Two important caveats: sticky sessions are still required for the WebSocket negotiation handshake, and messages are not buffered if Redis goes down temporarily. The post also compares the Redis backplane to Azure SignalR Service, recommending the former for self-hosted or latency-sensitive setups.

Redis Backplane vs. Azure SignalR Service