𝗪𝗵𝗮𝘁 𝘄𝗼𝗿𝗸𝘀 𝗳𝗼𝗿 𝗦𝗶𝗴𝗻𝗮𝗹𝗥 𝗹𝗼𝗰𝗮𝗹𝗹𝘆 𝗰𝗮𝗻 𝗳𝗮𝗶𝗹 𝗶𝗻 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻

Here's what I've learned while taking SignalR web applications from local development to production.

⚡𝗔𝘂𝘁𝗵 𝘄𝗼𝗿𝗸𝘀 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆.

Browsers don't let the client set the Authorization header on the WebSocket handshake, so the access token goes in the query string.

⚡𝗜𝘁 𝗰𝗮𝗻 𝗳𝗮𝗹𝗹 𝗯𝗮𝗰𝗸 𝗳𝗿𝗼𝗺 𝗪𝗲𝗯𝗦𝗼𝗰𝗸𝗲𝘁𝘀 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗯𝗿𝗲𝗮𝗸𝗶𝗻𝗴 𝘆𝗼𝘂𝗿 𝗮𝗽𝗽.

Locally, you may be using WebSockets without realizing it. In production, a missing IIS WebSocket feature can prevent WebSockets from being used.

SignalR can then fall back to Server-Sent Events or Long Polling.

⚡𝗜𝗻𝗰𝗼𝗺𝗶𝗻𝗴 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝗮𝗿𝗲 𝗹𝗶𝗺𝗶𝘁𝗲𝗱 𝘁𝗼 𝟯𝟮 𝗞𝗕 𝗯𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁.

SignalR's maximum receive message size defaults to 32 KB for a single incoming hub message. If it exceeds this limit, SignalR throws an error, and the connection is closed.

You can increase the message size limit, but blindly increasing it will also increase memory usage.

⚡𝗜𝘁 𝘄𝗼𝗿𝗸𝘀 𝘄𝗶𝘁𝗵 𝗼𝗻𝗲 𝘀𝗲𝗿𝘃𝗲𝗿, 𝘁𝗵𝗲𝗻 𝗯𝗿𝗲𝗮𝗸𝘀 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝘀𝗰𝗮𝗹𝗲.

With multiple API instances, each SignalR connection belongs to a specific server. If another instance sends a message, it doesn’t automatically know about the connections on the other servers.

If your SignalR server is running behind a load balancer, plan for cross-server message distribution using a backplane such as Redis or Azure SignalR Service.

The irony is, I switched to Ably after learning all of these hard lessons.

What's the hardest SignalR issue you've hit in production?

I share more engineering notes and production lessons on LinkedIn: Dipendra Neupane.

Comments

[Harun - solo dev]

dipendra, this is a brutally accurate summary of the "works on my machine" signalr trap. the transition from single-node statefulness to distributed statelessness is exactly where real-time systems reveal their cracks.

your point about the 32kb default limit is a classic pain point. instead of blindly raising MaximumReceiveMessageSize (which opens the door to memory exhaustion attacks), a more resilient pattern for large payloads is to implement application-level chunking or switch to a blob storage reference (e.g., sending a presigned url via signalr, then letting the client download the payload via standard http).

regarding the redis backplane: when network partitions occur between nodes, how do you handle connection state reconciliation? do you rely purely on the client's automatic reconnect logic to re-establish the session, or do you implement a custom heartbeat/acknowledgment layer to ensure no messages are dropped during the failover window?

switching to a managed service like ably makes total sense to offload that operational complexity. fantastic, battle-tested breakdown. 🐯⚡