SFU vs MCU vs P2P: Choosing the Right WebRTC Media Server Architecture

Three architectures carry almost every WebRTC video product, and they differ in one thing: where the media flows. Peer-to-peer (P2P) connects participants directly, with no media server in the path. An SFU (Selective Forwarding Unit) receives each participant’s stream once and forwards it to everyone else without re-encoding it. An MCU (Multipoint Control Unit) receives every stream, mixes and transcodes them server-side, and sends each participant a single combined feed. There is no “best” architecture in the abstract — the right one depends on participant count, privacy and compliance requirements, client-device constraints, and budget. This piece gives you a decision framework you can apply to your own product, not a single universal answer, and hands you off to a vendor comparison once you’ve decided you need a SFU at all.

Key takeaways

• P2P has no media server, so it’s the cheapest and most private option — but it only scales to a handful of participants. In a full-mesh topology, each participant uploads a separate stream to every other participant, so bandwidth and CPU cost on the sender’s device grow with group size; most builds move off naive mesh in the low single digits of concurrent senders, depending on device and bandwidth headroom.
• SFU is the standard architecture for scalable group video (roughly 5 to hundreds of participants). It forwards streams without re-encoding, so it costs far less server-side compute than an MCU, but each client must upload once and download multiple incoming streams.
• MCU mixes streams server-side into one combined feed. It costs the most in server compute (it transcodes every stream) but is the only option when client devices can’t decode multiple simultaneous streams — legacy hardware, some broadcast-style rooms, and SIP/telephony interop.
• Privacy- and compliance-driven products often favor P2P specifically because there’s no third-party media routing to secure or audit. Trembit’s KBV-certified psychotherapy platform, webPRAX Face2Face, uses P2P WebRTC on Germany-only infrastructure with on-premise STUN/TURN and zero third-party media routing, for exactly this reason.
• Most production video products that scale past a handful of users end up on an SFU — it’s the pragmatic default unless a specific constraint (privacy, a legacy client, or extreme scale) points elsewhere. Trembit’s Stusan enterprise platform runs a custom SFU handling 200+ simultaneous participants.
• Decide the architecture before writing product code, not after hitting a wall in production. Reversing the choice later means re-architecting the media layer while live users depend on it — a far more expensive fix than getting it right up front.

If you already know your scale and constraints and just want the answer, skip to How do you actually choose — the four-axis framework is the core of this piece.

What’s the actual difference between P2P, SFU, and MCU?

The difference comes down to where the media is processed and how it flows between participants.

In P2P (mesh), every participant sends their own audio and video directly to every other participant. There’s no server in the media path — just a signaling server to help peers find each other and negotiate the connection (the SDP offer/answer exchange and ICE candidate gathering defined in the WebRTC specification). Media stays end-to-end between browsers. That makes it private and cheap to run, but the cost lands on the client: in a group of N people, each participant uploads N-1 copies of their own stream. The upload burden grows with every person you add.

In an SFU, every participant sends their stream to a central server once. The server then forwards (“selectively forwards”) each stream to the other participants without decoding or re-encoding it. The client’s upload stays constant no matter how large the group gets — it uploads one stream and downloads several. The server does relatively little CPU work because it isn’t transcoding; it’s routing. This is the topology behind most modern group-video products.

In an MCU, every participant sends their stream to a central server, and the server mixes and transcodes all of them into a single combined stream that it sends back to each participant. The client uploads one stream and downloads one stream — the lightest possible client load — but the server pays for it, doing full transcoding work for every session. These roles map to the receiver/mixer topologies described in the IETF’s RFC 7667, RTP Topologies.

<!– [IMAGE: diagram-1-architecture-comparison.svg — place here, immediately after the table] alt: Diagram comparing WebRTC media flow in P2P mesh, SFU selective forwarding, and MCU stream-mixing architectures, showing server load and client bandwidth differences –>

The table is the fast version. The sections below are when to reach for each.

When should you use peer-to-peer (P2P) WebRTC?

P2P fits four situations: 1:1 calls; small group calls (roughly 2–4 participants) where a mesh is still viable; privacy-first or compliance-driven products where you want zero third-party media routing; and low-budget or early-stage products that don’t yet need to scale.

The honest trade-off is the mesh math. Because each participant sends a separate upload stream to every other participant, the sender’s bandwidth and CPU cost climb with group size — a full mesh means N-1 upload streams per person. That’s why naive P2P breaks down fast in the low single digits of participants: the next person to join isn’t just one more download for everyone, they’re one more upload from everyone. The exact ceiling is bandwidth- and device-dependent rather than a fixed constant — a fibre-connected desktop tolerates more concurrent uploads than a phone on mobile data — but the shape of the curve is the same, and it climbs fast. For a two- or three-person call, though, P2P is the simplest, lowest-latency, cheapest thing you can ship, and it keeps media off any server you’d otherwise have to secure and audit.

That last property is why P2P is often the right choice — not a lesser one — for regulated healthcare and legal products. Trembit’s webPRAX Face2Face is the clearest example: it’s the first psychotherapy video platform to achieve KBV certification in Germany, and it runs on P2P WebRTC on Germany-only infrastructure, with on-premise STUN/TURN servers and zero third-party media routing — media never touches infrastructure the platform doesn’t fully control. End-to-end encryption is auditable by external certification bodies, and the platform is used daily by thousands of therapists. The architecture wasn’t chosen for scale; it was chosen because keeping media off any central server was the cleanest way to meet a compliance bar that treats third-party media routing as a liability — a textbook case of the privacy axis (below) overriding the scale axis.

When should you use an SFU (Selective Forwarding Unit)?

An SFU fits group video from around 5 participants up to hundreds, and it’s the default choice for most scalable video products — webinars, virtual classrooms, group telehealth, enterprise conferencing. It works because it moves the heavy lifting to the right place: clients still do the encoding (which they’re already doing anyway), and the server just routes streams instead of transcoding them. That keeps server compute cost well below an MCU’s while still letting the group grow far past what a mesh can handle.

The cost that moves onto the client is download: each participant receives multiple incoming streams, one per other active speaker, so clients need enough bandwidth and CPU to decode them. The short version for non-engineers: keeping quality stable as the room grows is a solved problem you configure, not one you build from scratch — but you do have to configure it, and getting it wrong is the usual reason a call “worked for five people and fell apart at fifteen.” The mechanism, for the engineers: it’s handled with simulcast (each client sends the server several quality layers of its own video, and the server forwards the layer each recipient can handle) and SVC (scalable video coding) — mechanisms defined in the WebRTC and codec specs that let a session degrade gracefully when one participant’s connection is weak rather than dragging everyone down. An SFU that isn’t tuned for simulcast and bandwidth estimation is the common cause of that fell-apart-at-fifteen failure.

Trembit’s Stusan enterprise conferencing platform is a production example on this end of the scale spectrum: a custom WebRTC SFU handling 200+ simultaneous participants, with screen sharing, a collaborative whiteboard, cloud recording with automatic transcription, and a white-label API. It’s the mirror image of webPRAX — same firm, opposite end of the scale/compliance trade-off — which is exactly the range this decision framework has to cover.<!– [IMAGE: diagram-3-proof-points.svg — optional proof-point callout, place here near the webPRAX/Stusan pairing] alt: Two Trembit production deployments: a KBV-certified P2P psychotherapy video platform and a 200-plus participant enterprise SFU conferencing platform –>

Which SFU should you use?

That’s the next decision, not this one — and it deserves its own comparison rather than a paragraph here. Once you’ve decided your product needs an SFU, the choice between Janus, mediasoup, LiveKit, Jitsi, and Kurento comes down to how much control you need versus how fast you want to reach production. See our Janus vs mediasoup vs LiveKit for telemedicine comparison for the compliance-heavy version, and our LiveKit vs mediasoup comparison for the general production decision.

When should you use an MCU (Multipoint Control Unit)?

The MCU is the least common choice in modern WebRTC, and it’s worth being honest about why: transcoding every participant’s stream server-side is CPU-intensive and expensive to scale, so most products that could use an MCU choose an SFU with client-side compositing instead. But there are still three situations where an MCU is the right — sometimes the only — answer.

The first is legacy or low-power client devices that can’t decode multiple simultaneous video streams. An SFU pushes several streams to each client and expects the client to lay them out; if the client can only handle one incoming video, the MCU’s single mixed feed is the only thing it can render. The second is broadcast-style rooms where every viewer needs one identical, pre-composited feed — a single “gallery view” sent out to many endpoints rather than each endpoint building its own layout. The third is interop with traditional videoconferencing and telephony hardware (H.323, SIP), where you’re bridging WebRTC to endpoints that expect a single mixed stream and can’t participate in a selective-forwarding session.

The trade-off to name plainly: the MCU offloads the client at the server’s expense, and server transcoding is the most expensive resource in the whole picture. Unless one of the three constraints above genuinely applies to your product, an SFU will almost always be the more economical path in 2026. Trembit has shipped production systems on P2P and SFU across healthcare and enterprise; the MCU pattern lives in this framework as an honest option for the constraints that require it, not as a house recommendation.

How do you actually choose between P2P, SFU, and MCU for your product?

Work through four axes in order. For most products, the first axis (scale) narrows the field, and the next three either confirm the choice or override it for a specific reason.

1. Participant count / scale. This is the coarse filter. For 1:1 or 2–4 participants, P2P is viable and simplest — no media server to run, lowest latency, lowest cost. At 5+ participants, or any product with unpredictable growth, you want an SFU; mesh upload cost breaks down and the SFU keeps each client’s upload flat regardless of group size. For very large single-feed broadcast, or rooms full of legacy clients that can only decode one stream, an MCU (or an SFU with server-side compositing) is the fit. If your realistic scale curve crosses from “handful” to “dozens” within the product’s first year, architect for the SFU now rather than shipping mesh and re-architecting later.

2. Privacy and compliance. Some products have a hard requirement that media not pass through third-party infrastructure — data-residency rules, “no third-party media routing” mandates, or audit regimes in healthcare, legal, and government. Where that requirement exists and the participant count is small, P2P is the first choice, precisely because there’s no media server to secure, contract for, or audit — the webPRAX/KBV pattern above. Where scale requires more than a mesh can handle, the fallback is an SFU on compliance-appropriate infrastructure (self-hosted, in-region, data-residency-specific hosting) with strong encryption and access control — not a hosted CPaaS whose media path you don’t control. This axis can override axis 1: a requirement for zero third-party routing can push a product to self-hosted P2P even when scale would otherwise suggest an SFU. Compliance-aware architecture is its own discipline — see Trembit’s Security & Compliance capability.

3. Client device constraints. Ask what your users’ devices can actually decode. Modern browsers and phones with decent bandwidth handle the multiple incoming streams an SFU sends without trouble — this is the common case. Legacy hardware, very low-bandwidth environments, or telephony/SIP interop may not be able to decode several streams at once, and that’s the classic reason to reach for an MCU: it hands the client a single mixed feed. If your product has to run on constrained or non-browser endpoints, this axis can force an MCU even where scale and cost would prefer an SFU.

4. Cost profile. The three architectures spend money in different places. P2P has essentially no media-server compute cost (you run signaling and TURN, not media routing) — but it doesn’t scale, so its “cheapness” is real only inside its participant ceiling. SFU has moderate server cost (routing, not transcoding) and scales predictably, which is why it’s the default for products that need to grow. MCU has the highest server compute cost because it transcodes every stream — you pay for the client-side relief it provides. There are no dollar figures here on purpose: real cost depends on concurrency, regions, and recording, and the honest version comes out of a capacity estimate, not a blog table.<!– [IMAGE: diagram-2-decision-tree.svg — the “screenshot-and-use-it” visual, place here right after the four-axis list] alt: Decision-tree flowchart for choosing a WebRTC architecture based on participant count, privacy and compliance requirements, client device constraints, and cost –>

The honest default: most products that scale past a handful of users land on an SFU. It’s the pragmatic middle — it scales far further than P2P without the transcoding bill of an MCU. But “pragmatic default” is not “universally best.” P2P wins on privacy and cost at small scale; the MCU wins when clients genuinely can’t handle multiple streams. Some products even blend topologies — running a 1:1 call peer-to-peer and promoting it to an SFU the moment a third participant joins — so “choose one architecture forever” isn’t the only option, though a hybrid adds its own signaling and state-management complexity. And whichever you choose, switching topology later — a P2P product outgrowing its mesh, say — means re-architecting the media layer while live users depend on it. That’s the kind of decision worth pressure-testing in an architecture review before you write product code, which is exactly what our WebRTC development and rescue team does in a free 30-minute review.

What happens if you choose the wrong architecture?

An architecture mismatch rarely announces itself at launch. It shows up later, as a symptom that looks like a bug but is really a topology problem.

The most common one: P2P that was fine at launch degrades badly the first time a customer runs a 10-person call. The mesh was never going to carry that group, but nobody hit it until a real customer did — and now the fix is a media-server migration, not a patch. A second pattern: an SFU that’s under-provisioned for the work it actually needs — not tuned for simulcast, bandwidth estimation, or selective forwarding — so quality collapses for everyone once the room fills. (This is the “works for 5, breaks at 15” failure, and it’s a configuration problem far more often than a rebuild.) A third: a team discovers a compliance requirement after the fact — data residency, or no third-party media routing — only to find they’ve already built on a CPaaS or hosted SFU whose media path they can’t control.

The fix isn’t always a full rebuild, and pretending it is does no one any favors. Sometimes it’s re-configuring or re-scaling the existing architecture; sometimes it genuinely is a topology change. Telling those two apart is a protocol-level diagnosis — assessing whether the problem lives in the media-server configuration or in the choice of topology itself. That’s the exact work in our WebRTC rescue playbook, and when the driver was CPaaS lock-in specifically, in our guide to migrating off Twilio.

Is there a future architecture beyond SFU and MCU?

Worth knowing about if you’re planning multi-year infrastructure: Media over QUIC (MoQ) is an emerging transport-layer approach some teams are evaluating for large-scale, low-latency delivery that pushes past what SFU-based WebRTC comfortably handles. It’s early — as of 2026 there are no independent benchmarks and no named production deployments to point to — so it doesn’t change the P2P/SFU/MCU decision you’re making today. Treat it as a horizon item, not a fourth option on the table. We cover the honest state of it, and where it might and might not fit, in MoQ vs WebRTC.