In a call where everyone sees everyone, N participants generate N x (N-1) streams. That number is fixed by the room, not by your architecture.
This is the thing that makes the SFU vs MCU vs mesh question tractable. No topology makes the quadratic go away. Each one moves it somewhere else — onto the client's uplink, onto the server's CPU, or onto the server's network interface. Choosing a topology is choosing which of those three you would rather run out of.
Most architectures are chosen by fashion. SFU is the current default, MCU sounds dated, and mesh sounds elegant. None of that predicts what breaks at your call size.
SFU vs MCU vs mesh: where each one puts the work
One sentence each, then the detail.
- Mesh — every participant sends directly to every other participant. No server in the media path. The client pays.
- MCU — the server decodes every stream, composites them into one picture, and re-encodes it. Each client sends one stream and receives one stream. The server's CPU pays.
- SFU — the server receives each stream once and forwards copies without decoding. Each client sends one stream and receives many. The server's network pays.
The interesting part is not the definitions — what an SFU is and why every video platform uses one covers those in full. It is where each one hits a wall, and how early.
Mesh: the client pays, and it runs out fast
In a mesh, each participant uploads a separate copy of their own stream to every other participant. That is N-1 uploads per person, and consumer uplink is the scarcest resource in the entire system.
A typical fixed-line connection offers 10 to 20 Mbps up. A mobile connection often has 2 to 5 Mbps. So a four-person HD mesh call already exceeds what many mobile users can sustain, and a six-person one is out of reach for most home connections.
Bandwidth is not even the hard limit. Each peer connection generally means a separate encode, so a five-person mesh asks the client to run four parallel video encoders. On a laptop that shows up as fan noise and thermal throttling; on a phone it shows up as dropped frames and battery drain. The device gives out before the network does.
Where mesh genuinely wins: two participants. For a one-to-one call, mesh is not a compromise — it is the optimal answer. No server in the media path means the lowest achievable latency, no infrastructure cost, and no third party holding the media. Any system that routes a two-person call through a server is spending money and milliseconds for nothing.
Past four or five, the work has to move to a server. The question is what the server does with it.
MCU: the server's CPU pays, and it is genuinely expensive
An MCU decodes every incoming stream, composites them into a single video frame, and encodes that frame for delivery. Every client sends one stream and receives one stream, no matter how many people are in the room.
That constant client cost is the whole point, and it is a real advantage. A ten-year-old device on a 1 Mbps connection can join a fifty-person MCU call, because from the client's perspective a fifty-person call and a two-person call are identical.
The bill lands on the server instead. Transcoding is orders of magnitude more expensive than forwarding — an SFU rewrites packet headers, while an MCU runs full decode, composite and encode pipelines in real time. Practical MCU capacity runs in the low tens of participants per machine, against hundreds for an SFU on comparable hardware, and published cost comparisons typically put MCU infrastructure at several times SFU infrastructure for the same concurrency.
There are two modes, and the difference between them is large. A single shared mix means one composite encode for the whole room, which is manageable. Per-participant layouts — where each person sees a view that excludes themselves, or a personalised arrangement — means one encode per participant, and the cost climbs with the room.
MCU also adds latency that the other two do not, because the mix cannot be produced until the contributing frames have arrived and been decoded. And it destroys information: once streams are composited, the client cannot change the layout, pin a speaker, or render tiles at different sizes, because it is receiving a picture rather than a set of streams.
MCU is treated as obsolete more often than it deserves. It remains the correct choice for interoperating with SIP and telephony endpoints that expect a single stream, for producing a single composite recording without a separate pipeline, and for any deployment where client devices are genuinely constrained and you control the room size. Dismissing it as legacy is a fashion judgement, not a technical one.
For everything else, the modern default keeps the streams separate.
SFU: the server's network pays, and the client decodes
An SFU receives each published stream once and forwards copies to subscribers without decoding. No transcoding means forwarding is cheap — mediasoup documents roughly 500 forwarded streams per CPU core — so the CPU limit that constrains an MCU largely disappears.
The cost reappears as bandwidth. The server sends N x (N-1) streams, which at an average 600 kbps puts a 40-person room near a full gigabit of egress from a single machine. The quadratic did not vanish; it moved from the client's uplink to the server's network interface, and onto your infrastructure bill.
And there is a second place it lands that catches teams out: the client's decoder. Each participant now receives up to N-1 separate streams and must decode every one it renders. A 7x7 grid is 49 simultaneous decodes, which no consumer device will do. This is the same constraint that limits how many camera feeds a surveillance operator can watch on one screen, and it is the reason large meetings cap visible tiles and forward only the most recent speakers.
Speaker-based forwarding is what makes large SFU rooms work at all. If the client renders nine tiles, the server forwards nine streams, and N x (N-1) collapses to roughly N x 9 — linear growth instead of quadratic. Almost every large-scale video product does this, and it is usually the difference between a topology that scales and one that does not.
The comparison, in one table
Choosing between SFU, MCU and mesh by call size
Call size is the primary variable. Everything else is a modifier.
Two modifiers override the table. If any significant share of your users are on mobile networks, drop the mesh row entirely — mobile uplink and battery make it unviable well before the bandwidth math says so. And if you need a single composite recording, an MCU produces it for free, while an SFU needs a separate mixing pipeline to do the same job.
Most production systems are hybrids
In practice these are not exclusive. A well-built platform uses mesh for two-party calls, switches to an SFU the moment a third person joins, and runs a separate mixing pipeline off the SFU when a composite recording or a stream to an RTMP endpoint is required.
That last piece is worth naming, because it is where the MCU quietly survives: recording and broadcast output is a mixing problem, so most SFU deployments end up running an MCU-shaped component beside the SFU rather than instead of it. The topology question is usually not which one, but which one where.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
mediasoup, Janus, Pion and LiveKit are all SFUs, and Janus and Kurento can also perform mixing — how to choose a WebRTC media server covers the selection. Building gives you control over the mesh-to-SFU switchover and the speaker-forwarding policy, which is the decision that determines whether large rooms work. It also means owning the mixing pipeline separately if you need composite recording, which is frequently underestimated.
Buy a cloud video API
Per-minute providers make the topology decision for you, which is genuinely useful when your call sizes are ordinary. The limits show up at the edges: you generally cannot tune the switchover point, change the forwarding policy, or add an MCU path for legacy interop if the provider does not already offer one.
Deploy a commercial platform
The middle path is a platform you run on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control — which matters here because egress and recording are exactly the two costs the topology choice determines. It is resilient by design rather than something you assemble.
Where it does not fit: if your product is one-to-one calling only, mesh needs no platform at all. And if your requirement is primarily SIP and telephony bridging, a dedicated conferencing MCU will serve that better than any WebRTC-first platform.
The Bottom Line
SFU vs MCU vs mesh is not a ranking. The same N x (N-1) work exists in all three; the topology only decides whether the client's uplink, the server's CPU, or the server's network absorbs it.
Pick by call size first. Mesh below five, SFU from five to a few hundred, cascading beyond that, and MCU whenever constant client cost or legacy interop matters more than layout control. Then cap the quadratic with speaker-based forwarding, which does more for scale than any topology change.
What's Next
If you have settled on an SFU, where the bottleneck actually moves as you scale one covers the three limits you hit in order, and what scaling past a single media server costs prices the egress side.
Frequently Asked Questions
What is the difference between SFU, MCU and mesh?
Mesh has no server — every participant sends their stream directly to every other participant. An MCU decodes all streams, mixes them into one picture and re-encodes it, so each client sends and receives exactly one stream. An SFU receives each stream once and forwards copies without decoding, so clients send one and receive many. The total work is the same in all three; only its location changes.
At how many participants does mesh stop working?
Around four to six, and sooner on mobile. Each participant uploads N-1 copies of their own stream, so a five-person HD call needs about 10 Mbps of uplink per person. Parallel encoding usually bites first — five participants means four simultaneous video encoders on the client device.
Is an MCU obsolete?
No, though it is often described that way. An MCU is the only topology where client cost stays constant regardless of room size, which makes it the right answer for constrained devices, poor networks, and interoperation with SIP or telephony endpoints that expect a single stream. It also produces a composite recording for free. What you give up is client-side layout control and some latency.
Why is an SFU cheaper to run than an MCU?
Because it never decodes the video. An SFU rewrites packet headers and forwards, which costs roughly 500 streams per CPU core. An MCU runs full decode, composite and encode pipelines in real time, which limits practical capacity to the low tens of participants per machine. The tradeoff is that SFU bandwidth grows quadratically with room size while MCU bandwidth does not.
Which topology has the lowest latency?
Mesh, because there is no server in the media path at all. An SFU adds one forwarding hop, which is small. An MCU adds the most, because the mixed frame cannot be produced until the contributing frames have arrived and been decoded.
How do large meetings with hundreds of people work on an SFU?
By not forwarding everything. If a client renders nine tiles, the server forwards nine streams rather than all of them, which turns quadratic growth into linear growth. Speaker-based forwarding combined with cascading across multiple servers is how essentially every large-scale video product operates.
Can I use more than one topology in the same product?
Yes, and most production systems do. A common pattern is mesh for two-party calls, an SFU from the third participant onward, and a separate mixing pipeline alongside the SFU for composite recording or broadcast output. Some platforms, including Samvyo, handle the switchover without the application having to manage it.
