Why Azure SignalR beats in-process SignalR when thousands of clients push live location
Real-time location is one of those features that looks simple on a whiteboard and painful in production. A mobile or IoT client connects, then every few seconds it reports GPS coordinates to the server, which must fan that update out to dashboards, maps, and other subscribers, accurately and on time.
ASP.NET Core SignalR can do that. The question is whether you keep the hub inside your .NET app or offload the connection layer to Azure SignalR Service. For low traffic, in-process is fine. For a large number of concurrent connections with frequent location broadcasts, Azure SignalR usually wins.
What “in-process” SignalR actually means
With the default setup, your Web API (or web app) owns the WebSocket (or long-polling) connections. The SignalR hub runs in the same process as your business logic. That is convenient: one deployable, one auth story, and for a few hundred clients it often works well.
The cost shows up under scale:
- Every open connection holds memory and a socket on your app instances
- Frequent messages (e.g. location every 2-5 seconds) drive CPU and bandwidth on those same instances
- Horizontal scale needs a backplane (Redis, Azure SignalR, etc.) so clients on instance A see messages from instance B
- App restarts, deployments, and autoscaling churn drop or reconnect thousands of sockets at once
Your API becomes both a business service and a connection farm. Those two jobs compete for the same resources.
What Azure SignalR Service changes
Azure SignalR Service sits as a managed connection broker. Clients still talk SignalR; your app still hosts hubs and decides who gets which messages. But the persistent connections terminate at the service, not on every app instance.
Your .NET app uses a lightweight server connection to the service and focuses on:
- Authenticating users and negotiating access tokens
- Applying domain rules (who may see which vehicle, tenant, or region)
- Receiving location events and deciding what to broadcast
- Persisting history or triggering side effects
The heavy lifting (keeping tens of thousands of WebSockets alive, buffering, and fanning out) moves off your app servers.
Why this matters for high-frequency location
Location tracking is a worst-case pattern for in-process SignalR:
- Many long-lived connections: drivers, devices, and operator dashboards stay connected for hours.
- Steady write rate: a few-second interval × thousands of clients is a constant stream, not an occasional chat message.
- Fan-out: one update may need to reach several dashboards, a map view, and related clients in near real time.
- Accuracy under load: if the hub process is busy GC-ing or serving HTTP APIs, location ticks delay or drop; the map “lies.”
Azure SignalR is built for that connection and fan-out load. Your app can scale for business throughput (ingest, authorize, store) while the service scales for connection count.
In-process vs Azure SignalR at a glance
- In-process: best for demos, internal tools, and modest concurrent users; simplest ops when one or two instances are enough.
- Azure SignalR: better when connection count grows, clients reconnect often, you run multiple app instances, or messages are high-frequency (like live GPS).
- Still your code: hub methods, groups, auth, and message payloads stay in your project. You are not rewriting the product, only where sockets live.
Practical tips for location-heavy hubs
- Put clients in groups by tenant, fleet, or map viewport so you do not broadcast every ping to everyone.
- Keep payloads small (coords, heading, timestamp, id): location ticks add up fast.
- Throttle or coalesce on the server if a device spams faster than the UI needs.
- Treat SignalR as the live path; persist last-known position asynchronously so reconnects can catch up.
- Plan reconnect and token refresh carefully: mobile networks drop often.
The takeaway
In-process SignalR is not “wrong.” It is the right default until your app is spending more effort babysitting sockets than delivering features. When many clients must report precise location every few seconds, Azure SignalR Service usually gives more stable fan-out, cleaner horizontal scale, and app servers that stay free for domain work.
If you are designing a live map, fleet, or field-ops product, we can help you choose the right real-time architecture before connection count becomes an incident.
