SFU vs MCU vs Mesh: Choosing the Right WebRTC Architecture

The hardest decision in a group-calling product is not which codec to use or which signaling library to adopt — it is the media topology. Once you pass two participants, the way streams are routed between them decides your bandwidth bill, your server fleet size, the maximum room you can support, and whether end-to-end encryption is even possible. There are three classic answers: mesh, SFU, and MCU. Each one is right for some room sizes and badly wrong for others, and the math is concrete enough that you can usually rule out two of them on paper.

This article works through the bandwidth and CPU economics of each topology, the techniques (simulcast and SVC) that make a modern SFU practical, and a size-based decision framework so you can match a topology to the room you actually have.

Mesh: everyone connects to everyone

In a mesh, there is no media server. Each participant opens a direct RTCPeerConnection to every other participant. For n people that is n(n-1)/2 connections in the room, and each client maintains n-1 of them. The signaling server only brokers offers, answers, and ICE candidates; the media never touches your infrastructure.

The killer is upload. Because there is no server to fan out a stream, each client must encode and send its own video separately to every other participant. Take a 5-person call where everyone sends 1.5 Mbps of video:

Per-client upload = (n - 1) × per-stream bitrate
                  = 4 × 1.5 Mbps
                  = 6 Mbps uplink, per participant

Per-client download = (n - 1) × per-stream bitrate
                    = 4 × 1.5 Mbps
                    = 6 Mbps downlink

6 Mbps of sustained upload is already above what many home and most mobile uplinks deliver reliably. At 6 participants it is 7.5 Mbps each; at 8 it is 10.5 Mbps. The encoder load scales the same way — the CPU has to produce n-1 encoded copies — so mesh tends to die somewhere around 4 to 6 participants on real hardware and real networks, sooner on phones.

Where mesh shines is the 1:1 call. With two people there is exactly one connection, zero server media cost, the lowest possible latency (one direct hop), and because nothing decrypts the media in the middle, you get end-to-end encryption for free — the DTLS-SRTP keys are negotiated directly between the two peers. For privacy-sensitive 1:1 products, mesh is not a compromise; it is the best option.

SFU: forward once, subscribe selectively

A Selective Forwarding Unit is a media server that each client connects to exactly once. A participant uploads a single copy of their stream to the SFU, and the SFU forwards (routes) that stream to whichever other participants are subscribed to it. The server does not decode or re-encode video — it shuffles encrypted RTP packets — which is why it scales so much better than mixing.

The asymmetry is the point. Client uplink stays flat at one stream regardless of room size, while downlink grows with the number of streams you subscribe to. For the same 5-person room:

Per-client upload   = 1 × 1.5 Mbps   = 1.5 Mbps  (flat, any room size)
Per-client download = 4 × 1.5 Mbps   = 6 Mbps    (scales with subscriptions)

Server ingress  = n × 1.5 Mbps              = 7.5 Mbps
Server egress   = n × (n - 1) × 1.5 Mbps  = 30 Mbps

The flat uplink is what makes large calls feasible: a phone on a weak connection only has to send 1.5 Mbps no matter how many people are in the room. The cost moves to the server's egress, which grows roughly with n², but server bandwidth is cheap and horizontally scalable in a way that a client's home uplink is not.

Simulcast and SVC: adapting per receiver

A naive SFU forwards one quality to everyone, which forces every receiver to handle the sender's full bitrate. Two techniques fix that:

• Simulcast — the sender encodes the same video at several independent resolutions and bitrates at once (for example 1080p, 540p, and 180p) and ships all of them to the SFU. The SFU then forwards the layer appropriate for each receiver: full resolution to a desktop on fiber, the small layer to a phone on cellular or to a participant shown as a thumbnail.
• SVC (Scalable Video Coding) — a single encoded stream contains nested layers (spatial and temporal) so the SFU can drop higher layers to reduce quality without the sender producing multiple encodings. SVC is especially effective with VP9 and AV1, which have mature SVC support, and it is more bandwidth-efficient on the uplink than simulcast because there is no duplicated base layer.

The codec you pick interacts heavily with these — see our codec selection guide for how VP9 and AV1 change the SVC story.

Production-grade open-source SFUs are plentiful in 2026: mediasoup (Node/C++), Janus, Jitsi Videobridge, LiveKit, and several Pion-based SFUs written in Go. They differ in API style and clustering model, but all implement the forward-once core and most support simulcast and at least some SVC. mediasoup exposes a low-level router/producer/consumer API that gives you fine control over which layer each consumer receives; LiveKit wraps similar machinery behind a higher-level rooms abstraction with managed simulcast; Jitsi Videobridge pioneered last-N forwarding (only forward the N loudest speakers) at scale. The right choice usually comes down to how much routing logic you want to own versus how much you want the framework to decide for you.

MCU: decode, mix, send one stream

A Multipoint Control Unit goes further than forwarding: it decodes every incoming stream, composites them into a single mixed picture (and a single mixed audio track), re-encodes that composite, and sends each participant one stream. From the client's perspective an MCU room looks like a 1:1 call — one stream up, one stream down — which is why MCUs were the answer for low-power endpoints and remain useful for constrained clients.

The price is server CPU. Forwarding a packet is nearly free; decoding and re-encoding video is not. Transcoding a single 720p stream can cost on the order of a full CPU core, and an MCU does that work for every stream in every room, continuously. As a rough intuition, mixing is commonly one to two orders of magnitude more expensive per stream than the packet forwarding an SFU does — that gap is exactly why the industry largely moved from MCU to SFU for general conferencing.

MCUs still earn their keep where mixing is the requirement, not a side effect:

• Legacy interop — bridging WebRTC to SIP endpoints or the PSTN, which expect a single mixed stream.
• Server-side recording and composition — producing one composited MP4 of the whole call.
• Broadcast handoff — generating a single feed to push into an RTMP/HLS pipeline.

Side-by-side comparison

The E2EE row deserves a note: an SFU never decodes media, so with WebRTC's insertable-streams / encoded-transform API you can add a layer of encryption that even the SFU cannot read — it forwards packets it cannot decrypt. An MCU has to decode to mix, so it inherently sees plaintext, which makes true end-to-end encryption impossible by construction.

Hybrids and the real 100-person room

Production systems rarely run a pure topology at scale. A 100-participant room does not subscribe each client to 99 video streams — that downlink would be absurd and no UI shows 99 tiles anyway. Instead an SFU is paired with selective subscription: clients subscribe only to the handful of streams currently on screen, driven by active-speaker detection and UI pagination. The other 90-odd cameras are still uploaded (or paused) but not forwarded to most receivers.

Audio is often handled differently from video. Because audio is cheap and you want everyone audible, some systems mix audio server-side (a small, targeted MCU-style operation) while keeping video on the forward-only SFU path. And recording is frequently done with a dedicated headless compositor — effectively an MCU instance whose only job is to produce one composited file — running alongside the SFU rather than replacing it.

A decision framework by room size

Match the topology to the largest room you must support gracefully, not the average:

For one-to-many broadcast at thousands of viewers, no interactive topology applies to the audience: the presenters stay on a low-latency SFU, and the viewing tier is served as HLS/LL-HLS through a CDN, accepting a few seconds of latency in exchange for near-unlimited reach.

Every topology still depends on connectivity

It is tempting to think a server-based topology sidesteps NAT problems — the SFU has a public address, so surely the client can always reach it. In practice, restrictive corporate firewalls and locked-down mobile networks block UDP outright and sometimes the SFU's signaling/media ports too. When that happens, the client-to-server leg falls back to a TURN relay exactly as a peer-to-peer call would. An SFU does not remove the need for TURN; it just moves the relay to the client→server edge.

That relay traffic is a real line item — our TURN cost optimization guide covers how to keep it from dominating your bill, and mobile clients hit these restrictive networks most often, as the mobile WebRTC guide details. Before you blame your SFU for connection failures, verify that the STUN/TURN servers your clients use are actually reachable; you can check that in seconds with our free ICE server tester.