[ EXECUTIVE TEARDOWN // TL;DR ] In-memory broadcast only reaches the local process — multi-instance real-time needs a shared backplane (Redis pub/sub). Scope subscriptions into rooms so each client receives only the streams it watches, collapsing bandwidth and CPU. Coalesce high-frequency sources on the server to a renderable frame rate before broadcasting. Handle backpressure at the source, not after it has already flooded the client. A single WebSocket server streaming telemetry to a few clients is a weekend project. Feeding thousands across multiple instances is systems work. I learned that on streamerOS: the “one process holds every socket” sketch sailed on one pod and face-planted the moment we scaled out. Each instance owns its own connection table, so A cannot fan out to subscribers that landed on B; broadcasts die at the process boundary and your graphs freeze. The horizontal-scaling problem Once you run more than one server process behind a load balancer, connections fan out across instances. An event that originates on one instance has to reach subscribers on all of them. In-memory broadcast only reaches the local process; you need a shared backplane so every instance hears every event. In the pattern I call Trinity Architecture, this cross-instance fanout lives in the orchestration tier — the UI stays dumb, render-only, and the adapter keeps payloads lean. I use a Serialization Adapter there too; on IntegrateX it stripped non-essential React Flow UI metadata before persistence and cut graph payloads 94%, and the same habit keeps telemetry frames tight. scale.ts // Redis pub/sub backplane → broadcast across every instance import { createAdapter } from "@socket.io/redis-adapter"; io.adapter(createAdapter(pubClient, subClient)); // emit anywhere; every instance's subscribers receive it metrics.on("tick", (m) => io.to("telemetry").emit("metric", m)); Rooms, not broadcasts Do not push every metric to every client. Scope subscriptions into rooms — per dashboard, per device, per tenant — so a client receives only the streams it is watching. This collapses bandwidth and CPU from O(clients × events) toward O(interested clients), which is the difference between a system that scales and one that melts at a few thousand connections. On streamerOS, moving from a global channel to roomed feeds stopped NIC spikes, trimmed CPU interrupts, and cut render thrash when operators flipped between views; the UI joined/left rooms via the orchestrator in my Trinity split, never from components. Coalesce at the source High-frequency sources emit faster than any client can render or any socket should carry. Sample or debounce on the server to a sane frame rate before broadcasting, so you push the latest truth at a rate the wire and the React reconciler can actually absorb. Budget is ~16ms at 60fps; a 200 Hz stream will starve the UI thread. Track last-value-wins per key and pre-aggregate counters server-side. Backpressure handled at the source beats backpressure discovered at the client. Scaling real-time is not about a faster socket. It is about making sure each event travels exactly as far as it needs to — and no further. For the single-server fundamentals and the React consumption side, see Real-Time Telemetry; the live systems are streamerOS and the CMZ portal. The instinct I bring to a team is deciding how far each event should travel before you scale out, not after the graphs freeze. ~/keep-reading 8 min readReal-Time Telemetry: Why Polling Lies, and WebSockets Don'tPolling dashboards lie between ticks — I learned that the hard way. Now I push telemetry over WebSockets for sub-second parity across every React client. 7 min readMongoDB Aggregation Pipelines: Stage Order Is the WinProfiling a clinical API taught me MongoDB aggregation pipeline optimization lives or dies on stage order: $match first on indexes, $lookup join performance, then explain. 7 min readSerialization Adapters: How I Cut Payloads by 94%Rich UI objects make terrible database records. A Serialization Adapter I built for IntegrateX split render model from transport record and cut payloads by 94%. YK Yaseen Khatib · MERN + AI Architect Ships autonomous AI products solo — five in the last twelve months. More about Yaseen → Need an engineer who can build this? I'm Yaseen Khatib — a Senior Full-Stack AI Engineer (MERN + TypeScript) who ships production AI systems solo. Open to senior and lead roles, remote or on-site. Get in touch →See what I've shipped Originally published at yaseenkhatib.streamerosai.com/blog/websocket-telemetry-at-scale/.