WebRTC at Scale: SFUs, Simulcast, and the Cost Curve

Q: What is the difference between an SFU, an MCU, and a WebRTC mesh?

They are the three ways to move real-time media between more than two people, and they differ in who duplicates and combines the streams. In a mesh there is no server: every participant connects directly to every other participant, so for N people each client maintains N−1 connections and uploads N−1 copies of its own camera. That gives the lowest latency and zero server media cost, but client upload grows linearly with room size and consumer uplinks saturate at around four or five participants. An MCU (Multipoint Conferencing Unit) decodes every incoming stream on the server, composites them into a single mixed picture, and re-encodes one output per participant — so each client uploads one stream and downloads one stream, the lightest possible client, at the cost of heavy per-room server CPU and an added transcoding-latency hop. An SFU (Selective Forwarding Unit) receives one upload per participant and selectively forwards those packets to everyone else without decoding or re-encoding, so each client uploads once and downloads N−1 streams while the server does cheap packet routing. The SFU is the default for group video because it decouples the scarce resource — client upload — from room size, which is the architectural move that makes group calls scale.

Q: Why does a WebRTC mesh stop working after about five participants?

Because in a mesh every client sends a separate copy of its own media to every other client, so upload bandwidth demand grows linearly with the number of participants while the connection count for the room grows as N(N−1)/2. Concretely, a five-person mesh call asks each device to encode and send its camera four times, once per peer; at 720p and roughly 2.5 Mbps per stream that is about 10 Mbps of sustained upload from a home connection that advertises 10 and often delivers six. The bottleneck is the asymmetry of consumer internet: download capacity is generous but upload is scarce, and mesh hammers exactly the scarce side. The call does not crash cleanly — it degrades, with the encoder throttling resolution, frames dropping, and audio desyncing, and it fails first for whoever is on the worst network, who is frequently the person you most need to hear. That is why mesh is the correct topology only for one-to-one calls and tiny rooms; any product that will host group calls should start on an SFU rather than trying to stretch a mesh under load.

Q: What is simulcast and why is it essential for SFU scaling?

Simulcast is the technique where each client encodes and uploads its camera at several resolutions at once — for example 180p, 360p, and 720p — and the SFU then forwards the layer that matches each receiver's available bandwidth and on-screen tile size, rather than forwarding full resolution to everyone. It is essential because an SFU's outbound bandwidth is what saturates first, and forwarding full-resolution video to participants who are displayed as small thumbnails is enormously wasteful: in a 49-tile grid, a viewer only needs 180p for a thumbnail, not 720p. With simulcast the SFU becomes a bandwidth allocator that hands each receiver the appropriate layer, which can cut egress by an order of magnitude for grid layouts. Scalable Video Coding (SVC) achieves the same outcome with a single layered bitstream the SFU can subset instead of separate simulcast encodings. Either way, layer selection is not a nice-to-have quality feature — it is the primary control on your egress bill, and any SFU you evaluate must support it. Pairing simulcast with last-N active-speaker forwarding, where only the few current speakers are sent at full quality, compounds the saving further.

Q: What actually dominates the cost of running real-time video infrastructure?

Two line items dominate, and neither is the media server's compute: outbound egress bandwidth and TURN relay. Egress is the SFU forwarding streams out to clients, and in an SFU it is structurally larger than ingress because every uploaded stream is fanned out to N−1 receivers; cloud egress is metered per gigabyte and is one of the most expensive commodities on a cloud bill, so simulcast layer selection and last-N forwarding are cost controls before they are quality features. TURN relay is the second: WebRTC uses ICE to find a direct peer-to-peer path, but when both peers sit behind symmetric NATs or restrictive firewalls the media must be relayed through a TURN server, which means it transits your infrastructure and counts as egress twice — in and back out. A meaningful minority of real-world sessions require relay, and enterprise networks push that fraction higher, so teams that assume peer-to-peer connectivity discover the relay bill only in production. A third, quieter cost is recording and transcoding, since composited recordings need an MCU-style mixing pipeline even when the live path is a pure SFU. Model egress and TURN explicitly in your unit economics or your cost-per-minute figure will be wrong.

Q: What is SFU cascading and when do I need it?

Cascading, sometimes called SFU federation, connects multiple Selective Forwarding Units into a tree so that a single room can be served by more than one machine and across more than one region. Participants connect to their geographically nearest SFU, and the SFUs forward streams to each other over the backbone exactly once per stream per edge, rather than once per participant — so the expensive cross-region traffic is amortised across everyone in a region instead of multiplied by the participant count. You need it for two reasons. First, capacity: a single SFU has a finite network interface and outbound bandwidth ceiling, and cascading is how you scale a large room past one NIC. Second, geography: real-time media is latency-brutal — around 150 ms of one-way delay is the edge of comfortable conversation — so you want each participant's first hop to land on a nearby server, then accept backbone latency between SFUs because it is shared. Cascading turns the media plane into a distributed system with the corresponding failure modes, so you apply cell-based, blast-radius thinking: a room is a unit of state, and a bad node should take down one region's leg of one room, not the whole room.

Q: Should I use a managed real-time platform or self-host an SFU like mediasoup or LiveKit?

Start managed and self-host only when the economics clearly justify it. A managed platform — LiveKit Cloud, Cloudflare Realtime, or similar — folds SFU operation, egress, and TURN into a single usage-priced product and removes the operational burden of running media servers, TURN fleets, and the on-call that comes with them, which is exactly what you want while you are proving the product and your volume is modest. You should move to self-hosting an open-source SFU such as mediasoup or LiveKit inside your own VPC only when the managed bill at your actual scale exceeds the fully-loaded cost of running it yourself — and "fully-loaded" must include the TURN infrastructure, the cascading and per-region cells, the recording pipeline, and the engineering and on-call time, not just the compute. This is a build-versus-buy decision governed by portability and unit cost rather than ideology, and it is a platform undertaking rather than a feature, so you should be able to demonstrate the crossover on a spreadsheet before you commit. Most successful real-time products live on a managed SFU with simulcast and regional endpoints for a long time before self-hosting ever pays.

Q: Do I still need TURN servers if my SFU is public on the internet?

Yes. It is a common misconception that a publicly reachable SFU removes the need for TURN, but TURN solves a different problem than server reachability. The issue is the client side: many participants sit behind symmetric NATs, restrictive corporate firewalls, or networks that block UDP, and for those clients ICE cannot establish a direct media path even to a public server. TURN provides a relay that the client can always reach — typically over TCP or TLS on port 443, which enterprise firewalls almost always allow — so the media flows client-to-TURN-to-SFU when a direct path is impossible. Without a TURN server, a predictable slice of your users simply cannot connect, and it will be disproportionately your enterprise customers on locked-down networks. So TURN is not optional infrastructure for a production real-time product; it is the connectivity floor that guarantees everyone can join. The catch is cost: relayed media transits your infrastructure and is billed as egress, effectively twice, so you must include the relayed fraction of sessions in your bandwidth model rather than assuming everyone connects peer-to-peer or directly to the SFU.

Q: When is an MCU still the right choice over an SFU in 2026?

The MCU still wins in a few specific situations, even though the SFU is the general-purpose default. The first is genuinely weak or constrained clients: an endpoint that cannot decode and render multiple simultaneous video streams — a low-power set-top box, an embedded device, or a legacy phone gateway — is far better served by an MCU that mixes everything into a single stream it can handle, since the MCU pushes the composition cost to the server and asks the client only to decode one picture. The second is when you need a single composited output as a first-class artifact: broadcast to an RTMP or HLS distribution chain, a recording that must be one mixed file, or a livestream where one canonical layout is the product. The third is bandwidth-pinned receivers where downloading N−1 streams is infeasible and a single mixed stream is the only way the call works at all. Outside these cases the SFU is cheaper to operate and lower latency because it avoids the per-room decode-mix-encode CPU load and the transcoding hop, so reaching for an MCU purely to reduce client download bandwidth is usually a mistake. Many production systems run a pure SFU for the live path and stand up an MCU-style pipeline only for recording.