Real-Time POS and Operations with ASP.NET Core SignalR

History and context

Where real-time actually matters

POS itself can often tolerate request-response APIs. Operational screens such as kitchen displays, preparation stations, dispatch boards and order-monitoring dashboards benefit from low-latency server push because state changes are produced elsewhere.

Reference real-time architecture

Use groups to target operational audiences

public Task JoinStation(int shopId, int stationId)
{
    var group = $"shop:{shopId}:station:{stationId}";

    return Groups.AddToGroupAsync(
        Context.ConnectionId,
        group);
}

Publish after durable state changes

await hubContext.Clients
    .Group($"shop:{shopId}:station:{stationId}")
    .SendAsync(
        "taskUpdated",
        stationTask,
        cancellationToken);

React client with reconnect

const connection = new HubConnectionBuilder()
  .withUrl("/hubs/stations")
  .withAutomaticReconnect()
  .build();

connection.on("taskUpdated", task => {
  upsertTask(task);
});

connection.onreconnected(async () => {
  await reloadStationState();
});

Why reconnect must reload state

A client may miss events during a network outage. Replaying every event is possible, but many operational UIs can use a simpler pattern: reconnect, then refetch the current authoritative state. That prevents the UI from assuming that the event stream itself is durable history.

Authenticate and authorise hub access

Hub connections must respect the same identity and permission model as ordinary APIs. Group names should not be treated as access control; server-side authorisation decides whether a connection is allowed to join a shop or station.

Scaling considerations

High-connection-count real-time systems require deliberate connection and hosting architecture. Microsoft's current ASP.NET Core guidance includes specific production hosting and scaling considerations for SignalR applications.

Business value and practical considerations

References