Real-Time with SignalR

HTTP is "Request-Response." But for chats, dashboards, and games, you need the server to Push data to the client. SignalR is the industry standard for real-time web in .NET.

1. Transport Fallbacks

SignalR is smart. It tries to use **WebSockets** first (the fastest). If the browser (or a corporate proxy) doesn't support them, it automatically falls back to **Server-Sent Events** or **Long Polling**. Your C# code stays the same regardless of the transport.

2. Hub Architecture

You define a **Hub** class. You can send messages to "All Users", "Specific UserID", or "Group" (e.g., everyone in 'ChatRoom-102'). This makes managing 10,000 concurrent sockets extremely simple.

3. SignalR Backplane

If you scale to 5 servers, Server A doesn't know about users connected to Server B. To fix this, you add a **Redis Backplane**. Server A sends a message to Redis, and Redis tells ALL 5 servers to push the message to their local users. This is how you scale real-time apps to millions of users.

4. Interview Mastery

Q: "How do you handle 'Security' in SignalR?"

Architect Answer: "SignalR uses the same authentication as your Web API (JWT or Cookies). We use the `[Authorize]` attribute on our Hubs. For extra security, we use **Token-based Authentication in the Query String** for the initial handshake, as headers aren't always supported in WebSocket connections. We also use **Rate Limiting** on the Hub to prevent a malicious client from spamming 'CallAll' and crashing other users' browsers."