Architecting Ultra-Low-Latency WebRTC and WebSocket Pipelines

13 November 2026

Edge fanout and state sync for interactive video

Interactive video breaks down into two problems that scale in different ways. The first is media: getting one publisher's stream to thousands of viewers without adding seconds of delay. The second is state: chat messages, presence, scores, reactions and every other small update that has to reach every viewer at roughly the moment the picture does. Teams that treat these as a single problem usually end up overloading one tier while the other sits idle.

For media, the usual answer is WebRTC with a selective forwarding unit, or SFU, which receives a stream and relays it to subscribers without transcoding it for each viewer. One SFU runs out of network capacity well before a large audience arrives, so the load has to spread across several. LiveKit's engineering write-up on scaling WebRTC with a distributed mesh describes this approach as cascading mode, in which many SFUs are linked and each serves the participants closest to it. A study on ultra-low-latency delivery over WebRTC data channels points the same way: regional clusters can replicate serialized streams to regional WebRTC services, and new servers are created as client counts increase.

State follows a different path. Redis documents pub/sub as a way to push real-time updates to WebSocket clients across multiple server nodes, which is exactly what a fleet of edge servers needs. A viewer connected to node A should see the message that another viewer posted through node B, and pub/sub is the channel that carries it between them. Each node subscribes to the topics its own clients care about and forwards whatever arrives to its local sockets.

The practical consequence is a clean division of labor. Media fans out through the SFU layer, where bandwidth is the scarce resource. State fans out through WebSockets and Redis, where message rate and connection count matter more. Keeping them separate means you can add SFUs when video traffic grows and add socket servers when the chat gets busy, without one change forcing the other.

Measuring latency and proving sub-second delivery

Before claiming a pipeline is fast, define what is being timed. The number that matters for viewers is glass-to-glass latency: the delay between something happening in front of the camera lens and that same moment appearing on the viewer's screen. It includes capture, encoding, network transit, any server hops, buffering and decoding. A server-side metric such as round-trip time or time to first byte captures only a slice of that, which is why dashboards can look healthy while viewers complain that the stream is behind.

Published figures give a sense of the range. Fora Soft's explainer on glass-to-glass latency puts WebRTC at 0.2 to 0.8 seconds in live video streaming contexts, which is the basis for calling sub-second delivery realistic rather than aspirational. A WebRTC benchmark on a local network reported 40 ms glass-to-glass, though a LAN result is a best case and says little about what a viewer across the country will see. The same ComputingForGeeks testing compared protocols on a clean LAN and found LL-HLS at 772 ms against 20.6 seconds for plain HLS. That gap is why chat-driven or interactive formats cannot be built on ordinary HLS without the audience noticing the lag.

Not every use case needs to chase the floor. A study on ultra-low-latency video delivery using WebRTC data channels says delays as low as 2 seconds can be achieved, and for some designs, particularly those that serialize streams and replicate them regionally, that is a sensible target. Deciding between sub-second and a couple of seconds is a product decision as much as an engineering one. It depends on whether viewers are reacting to what they see, as with live auctions, game feeds or Q&A, or simply watching.

In practice, the most reliable way to measure is also the simplest. Put a running timestamp or frame counter in front of the camera, point the camera at it, then photograph the source and the viewer's screen side by side. The difference between the two readings is your glass-to-glass figure, and it works regardless of which servers sit in the middle. Repeat it from several networks and devices, and at different load levels, because a median taken at 3 a.m. with ten viewers hides the behavior you care about. Developers testing sub-second video feeds alongside high-frequency state synchronization can examine operational network profiles across platforms like the best live dealer casinos for Americans to benchmark adaptive bitrate handling under peak concurrent loads. Whatever reference you use, record the same numbers each time: end-to-end delay, dropped frames and how quickly quality recovers after a throttled connection.

Load balancing and horizontal scaling for WebSockets

The WebSocket side of the pipeline follows a well-worn pattern. Ably's write-up on scaling pub/sub with WebSockets and Redis describes a typical architecture as a WebSocket server handling client connections, with Redis acting as the pub/sub layer behind it. In front sits a load balancer such as NGINX or AWS ALB, which routes incoming WebSocket connections across multiple server instances. The pieces are simple individually; the value comes from how they divide responsibility.

The components that make up the standard setup:

• Connection layer: WebSocket servers that hold open client connections and push messages to them.
• Load balancer: NGINX or AWS ALB, distributing incoming WebSocket connections across server instances.
• Redis pub/sub: the shared channel that carries messages between server nodes so every client receives updates regardless of which node it landed on.
• Stateless servers: instances that keep no authoritative data of their own, so any of them can be added or removed as demand changes.

The last item is where many first attempts go wrong. If a server stores room membership or message history only in its own memory, a client reconnecting to a different instance, which a load balancer is free to arrange, finds nothing. Pushing shared state out to Redis, and treating each socket server as a disposable relay, is what lets you scale horizontally without special routing rules. It also makes deployments less painful, since you can drain and replace nodes while clients reconnect to whichever instance has room.

There is a caveat worth planning for. A WebSocket is a long-lived connection, so a load balancer distributes new connections evenly but cannot rebalance existing ones. After you add servers during a traffic spike, the older nodes keep their clients while the new ones start nearly empty. Plan for this by setting reasonable connection lifetimes or by having clients reconnect on a schedule, and test the reconnect path under load, because a thousand clients reconnecting at once creates its own surge.

Stress-testing at high concurrency

Architecture diagrams are cheap; benchmarks show where designs bend. LiveKit's engineering article on its distributed mesh gives one of the larger public data points for WebRTC. Its 100k participant benchmark used 100,000 participants consuming 1080p video over WebRTC, and the run reported 225 Gbps of peak traffic across 132 SFUs in cascading mode.

Those figures say something useful about planning. At that scale the constraint is aggregate network throughput, not any single machine, which is why the work was spread over more than a hundred SFUs rather than a handful of large ones. A 225 Gbps peak also tells you what to budget for: egress bandwidth is the line item that grows fastest with audience size, and it grows with the resolution you choose to deliver. Anyone sizing a deployment can work backward from the same shape of numbers, starting with the audience, the video quality per viewer and the traffic that results.

Your own tests do not need to reach six figures to be informative. Start with a load generator that behaves like real clients, joining, subscribing to video, sending and receiving state messages, and dropping off, rather than one that merely opens sockets. Ramp concurrency in steps and watch both halves of the system: glass-to-glass delay on the media side, and message delivery time through Redis pub/sub on the state side. If delay climbs on one while the other holds flat, you know which tier to scale.

The takeaway for a team shipping this year is to test the two paths separately, then together. Set a latency budget you can defend with measured glass-to-glass numbers, keep socket servers stateless behind the load balancer, and add SFUs in a cascade as audience size demands. Run the stress test before launch day, not during it.