WebRTC Architectural Patterns: P2P vs. MCU vs. SFU

WebRTC makes it deceptively easy to get two browsers exchanging audio and video directly, peer to peer, with no server touching the media at all. The moment a third participant joins the call, that simplicity starts to cost you — and by the time you're building a product meant to support real group calls, the way you route media between participants is one of the most consequential architecture decisions you'll make. There are three well-established patterns for this: mesh (peer-to-peer), MCU, and SFU. Each makes a different trade between client cost, server cost, latency, and flexibility.

Mesh: everyone connects to everyone

The simplest way to extend a 1:1 call to a group is to keep doing exactly what worked for two people: every participant opens a direct peer connection to every other participant. No media server sits in the middle at all — video and audio flow client to client, encrypted end to end, with no infrastructure cost for the media path itself.

The problem is how the cost scales. In a mesh of N participants, each client must encode and upload its own stream N-1 times — once per remote peer, since a single encoded stream can't be shared across independent peer connections the way it can through a server. A 5-person call means each participant is uploading four separate copies of their video and decoding four incoming streams simultaneously. Both upload bandwidth and CPU (encoding is expensive; most clients end up encoding multiple resolutions or doing it multiple times over) grow linearly with group size, on every single participant's device — including the one on a shaky hotel Wi-Fi connection or a five-year-old laptop.

In practice, mesh tops out somewhere around four to six participants. Past that, the weakest device or the weakest connection in the call degrades everyone's experience, because that participant simply cannot keep up with N-1 simultaneous encodes and decodes. Mesh topologies are a great fit for small, casual group calls or peer-to-peer file/screen sharing, but they are not an architecture you build a video conferencing product on.

MCU: one server, one mixed stream

The Multipoint Control Unit (MCU) model flips the problem entirely onto the server. Every participant uploads exactly one stream — to the server, not to each other. The MCU receives all of those streams, decodes every one of them, composites/mixes them into a single combined stream (think: a grid layout baked directly into the pixels, or a single mixed audio track), and re-encodes that composite before sending it back down to each client.

From the client's point of view, this is wonderful: bandwidth and CPU usage are low and, critically, constant regardless of how many people are in the call — you're always just uploading and downloading one stream. This is exactly why MCUs were the dominant architecture in the era of dedicated video conferencing hardware (room systems, legacy telephony-style endpoints) that had no spare CPU for decoding a dozen independent incoming streams.

That extra hop is the other real cost of an MCU: every participant's video is delayed by however long it takes the server to decode, composite, and re-encode it, on top of ordinary network transit time. For a product where low latency matters — which is most modern video calling — that added hop is hard to justify once a cheaper alternative exists.

SFU: forward, don't transcode

The Selective Forwarding Unit (SFU) keeps the MCU's best idea — clients upload once, to a server, not to every peer — and drops the expensive part. An SFU receives each participant's stream and forwards it unchanged to whichever other participants need it. It never decodes the media, never mixes it, and never re-encodes it; it operates on encrypted RTP packets at the routing layer, not on decoded pixels.

This single difference changes the economics of the whole architecture. Client upload cost stays exactly as good as an MCU — one encode, one upload, regardless of group size. But server cost drops enormously, because forwarding packets is orders of magnitude cheaper than decoding and re-encoding video streams. An SFU host can support far more concurrent participants per server core than an MCU ever could, because it's doing I/O and packet routing, not transcoding.

The trade SFUs make instead is pushing decode cost back out to the clients: in an N-person SFU call, each client still receives and decodes up to N-1 incoming streams. That's real cost, but modern client hardware and hardware-accelerated video decode handle multiple simultaneous decodes far more comfortably than multiple simultaneous encodes — decoding is simply cheaper than encoding. SFUs lean on this asymmetry, along with techniques like simulcast (a client encoding two or three quality tiers so the SFU can forward a lower-resolution version to a participant on a small tile or weak connection) to keep bandwidth and CPU usage manageable even in large calls.

Because the SFU never touches the actual pixels, it also preserves flexibility an MCU permanently throws away. Since streams aren't pre-mixed into one baked composite, an SFU can forward different quality tiers of the same stream to different recipients, drop a participant's video entirely for a listener who's only interested in audio, or let each client render its own layout locally. An MCU baked all of that into pixels on the server, once, for everyone — an SFU defers those decisions to the edge, per client, where they belong.

The trade-offs, side by side

Put the three side by side and the pattern is consistent: mesh pushes all cost onto clients and fails to scale past a handful of people; MCU pushes cost onto the server in the most expensive way possible (transcoding) in exchange for trivial, constant client cost; SFU pushes upload cost onto clients just once each, keeps server cost low by never touching the actual media, and accepts a modest, well-handled increase in client-side decode work in exchange for it. On client bandwidth, mesh scales with N, while MCU and SFU both stay roughly constant on upload. On client CPU, mesh again scales with N (multiple encodes), MCU stays flat, and SFU stays flat on encode but grows modestly on decode as participants are added. On server cost, mesh has none, MCU is high and scales with transcoding load, and SFU is low and scales mostly with bandwidth, not compute. On latency, mesh is lowest (direct paths, no server hop at all), SFU adds only routing latency, and MCU adds a full decode-mix-encode pass on top of that. On flexibility, MCU is the least flexible — one fixed composite for everyone — while SFU allows per-client resolution, layout, and stream selection, and mesh is flexible only because there's no server imposing any structure at all.

Which one actually fits your product

For a pure 1:1 call, mesh is not just adequate, it's ideal — there's no group-scaling problem with only one peer connection, and skipping a media server entirely removes cost and an extra network hop. For anything from small group calls up through large-scale video conferencing, SFU is the modern default, and for good reason: it's the only one of the three that scales server cost sublinearly while keeping client cost flat and latency low, which is exactly the combination a general-purpose video product needs. MCUs haven't disappeared, but they're now a specialist tool — bridging to legacy hardware conferencing endpoints that expect a single incoming stream, interoperating with telephony systems, or producing a single mixed recording/broadcast output where having the server bake one composite stream is the actual goal rather than a limitation to work around.