Scaling WebSocket Telemetry Across Multiple Servers Requires a Shared Backplane

Running a WebSocket telemetry server on a single process works fine at small scale, but breaks down once multiple instances are deployed behind a load balancer, as each instance maintains its own connection table and cannot broadcast to subscribers on other instances. A shared backplane such as Redis pub/sub solves this by ensuring every instance receives every event, regardless of where it originated. Scoping subscriptions into rooms — per dashboard, device, or tenant — further reduces unnecessary bandwidth and CPU usage by delivering events only to interested clients. High-frequency data sources should be sampled or debounced server-side to a renderable frame rate, around 16ms for 60fps, before being pushed to clients. These architectural decisions — backplane selection, subscription scoping, and server-side coalescing — should be made before scaling out, not after performance problems emerge.