Mesh vs SFU vs MCU: Choosing WebRTC Architecture That Scales

Building a WebRTC application is deceptively easy.

You can open a camera, create a peer connection, exchange SDP, send ICE candidates, and get two browsers talking in surprisingly little code. The difficult part starts when the application needs to support 10, 50, 500, or thousands of simultaneous participants.

At that point, your media architecture becomes one of the most important engineering decisions you make.

The choice between Mesh, SFU, and MCU affects bandwidth consumption, server infrastructure, latency, CPU usage, implementation complexity, feature flexibility, and ultimately the maximum size of your application.

There is no universally "best" WebRTC topology. A two-person calling application has very different requirements from a 500-person webinar, a telehealth platform, or an interactive virtual classroom.

This article breaks down the three main architectures, explains where each one works, and provides a practical framework for choosing the right approach.

The Three Main WebRTC Topologies

At a high level, WebRTC media can be distributed using three common approaches:

• Mesh: Every participant connects directly to every other participant.
• SFU (Selective Forwarding Unit): Participants send media to a server, which selectively forwards streams to other participants.
• MCU (Multipoint Control Unit): A server receives, decodes, mixes, and re-encodes multiple streams into one or more composite streams.

The fundamental difference is where the media processing happens.

With Mesh, most of the work happens on the clients.

With an SFU, the server routes media but generally does not decode and re-encode every stream.

With an MCU, the server performs significantly more media processing.

That difference becomes critical as participant counts increase.

Mesh: Simple and Direct

In a Mesh architecture, every participant establishes a peer-to-peer connection with every other participant.

For a call with four participants, each browser may maintain three outgoing connections and three incoming connections.

If there are N participants, the number of peer-to-peer relationships grows approximately as:

N × (N - 1) / 2

The problem is that each participant must send its media stream separately to every other participant.

Example: A Four-Person Call

Assume each participant sends a 1.5 Mbps video stream.

With four participants, one user potentially needs to upload approximately:

1.5 Mbps × 3 = 4.5 Mbps

That's manageable on a good connection.

Now increase the call to 10 participants:

1.5 Mbps × 9 = 13.5 Mbps

The upload requirement quickly becomes unrealistic for many consumer devices and networks.

Advantages of Mesh

Mesh is attractive because the infrastructure requirements are minimal.

Pros:

• Very low server-side media cost
• Extremely low server latency
• Direct peer-to-peer communication
• Simple architecture for small applications
• No media server required for basic calls

For a two-person call, Mesh is often perfectly reasonable.

Disadvantages of Mesh

The scaling problem is fundamental rather than implementation-specific.

Cons:

• Upload bandwidth grows with participant count
• CPU and encoding workload can increase significantly
• Connection management becomes complicated
• Network conditions vary between every peer
• Large group calls become difficult to support reliably

A practical limit depends on codec, resolution, simulcast, device capability, and network quality, but Mesh generally becomes uncomfortable for interactive group calls somewhere around 4–6 participants.

It can work beyond that in controlled environments, but it is rarely the architecture you want for a large production conferencing platform.

SFU: The Practical Default for Group Calls

An SFU changes the model.

Instead of every participant sending media directly to every other participant, each participant sends its media to a central server.

The SFU then forwards selected streams to the other participants.

Importantly, a typical SFU does not need to decode and re-encode every video stream.

That makes it much more efficient than an MCU.

How SFU Works

Imagine a six-person meeting.

Each participant sends one video stream to the SFU:

User A ─┐
User B ─┤
User C ─┤
User D ─┼──> SFU ──> Participants
User E ─┤
User F ─┘

The server receives the streams and decides which ones should be forwarded to which participants.

The SFU can make forwarding decisions based on:

• Active speaker
• Available bandwidth
• Device capabilities
• Screen sharing
• Subscription preferences
• Video quality
• Spatial regions in a virtual room

This is where technologies such as mediasoup, Janus, and LiveKit become useful. They provide building blocks for implementing sophisticated real-time media routing without building every media-server component from scratch.

SFU Bandwidth

Suppose each participant sends a 1.5 Mbps stream.

With six participants, every client only needs to upload roughly 1.5 Mbps to the SFU rather than sending five separate copies.

The download requirement still depends on how many streams the client subscribes to.

This is a major improvement over Mesh.

With simulcast or scalable video coding, the SFU can also forward different quality layers to different users.

For example:

Publisher
   |
   +-- 180p
   +-- 360p
   +-- 720p
   |
   v
  SFU
 / | \
Low Mid High

A mobile user on a weak connection might receive a lower-quality stream while a desktop user on a fast connection receives 720p.

Advantages of SFU

Pros:

• Much better scalability than Mesh
• Lower server CPU than MCU
• Supports selective subscriptions
• Works well with simulcast
• Good balance between latency and infrastructure cost
• Flexible enough for modern conferencing products

Disadvantages of SFU

SFUs aren't free from complexity.

You need to design:

• Signaling
• Room management
• Authentication
• NAT traversal
• STUN/TURN infrastructure
• Media routing
• Subscription management
• Recording
• Monitoring
• Horizontal scaling
• Failure recovery

The SFU itself may handle media efficiently, but your surrounding system still needs strong engineering.

A well-designed SFU architecture can support dozens or hundreds of participants per room, depending heavily on resolution, codec, subscription patterns, simulcast configuration, hardware, and server capacity.

For very large rooms, you may need multiple SFUs and regional distribution.

MCU: Centralized Media Mixing

An MCU takes a fundamentally different approach.

Instead of simply forwarding streams, it receives media, decodes it, mixes or processes it, and generates new output streams.

For example, an MCU could combine several video feeds into one 2×2 grid:

+-------+-------+
|   A   |   B   |
+-------+-------+
|   C   |   D   |
+-------+-------+

The client receives a single composite stream instead of subscribing to multiple individual feeds.

Why Use an MCU?

MCUs can simplify certain client-side scenarios.

A low-powered device might not have to decode eight separate video streams. The server can perform the mixing instead.

MCUs can also be useful when the application requires:

• Server-side composition
• Consistent layouts
• Broadcast-style output
• Legacy interoperability
• Specialized media processing

The Cost of MCU

The downside is CPU.

Decoding and re-encoding video is expensive.

If you have 100 participants sending multiple high-resolution streams, the MCU may need substantial compute resources just to process the media.

That makes MCU-based architectures more expensive to scale horizontally.

Advantages of MCU

Pros:

• Server-side composition
• Predictable output stream
• Reduced client decoding workload
• Useful for broadcast and recording workflows
• Good fit for certain legacy integrations

Disadvantages of MCU

Cons:

• High CPU requirements
• More infrastructure cost
• Additional processing latency
• More complicated media pipelines
• Scaling requires careful capacity planning

MCUs can work very well, but they are usually chosen because the application needs server-side media processing, not simply because it needs group video.

Mesh vs SFU vs MCU: Quick Comparison

Factor	Mesh	SFU	MCU
Typical participants	2–4	4–100+	4–100+
Client upload	High	Low/moderate	Low
Server CPU	Very low	Moderate	High
Server bandwidth	Low	High	High
Latency	Very low	Low	Low/moderate
Architecture complexity	Low	Medium/high	High
Media processing	Client	Forwarding	Decode/mix/re-encode
Simulcast support	Limited value	Excellent	Possible
Large meetings	Poor fit	Strong fit	Possible
Server-side layouts	Limited	Possible through additional services	Excellent
Cost at scale	Client/network dependent	Usually efficient	Infrastructure intensive
Best use case	Small calls	Conferencing	Media mixing/broadcast

These are architectural tendencies rather than hard limits. Actual capacity depends on codecs, resolutions, packet rates, hardware, network conditions, and application behavior.

Hybrid Architectures: The Real World Is Messier

Production systems don't always fit neatly into one topology.

A large application may use different architectures for different workflows.

For example:

• Mesh for one-to-one calls
• SFU for group meetings
• MCU-style composition for recordings
• SFU for interactive participants
• Broadcast infrastructure for thousands of viewers

A webinar could have 10 interactive speakers connected through an SFU while thousands of viewers receive a separate broadcast stream.

This avoids forcing every viewer into the expensive interactive conferencing architecture.

SFU + Recording Pipeline

Another common pattern is:

Participants
     |
     v
    SFU
   /   \
  v     v
Clients  Recorder
           |
           v
       Object Storage

The SFU handles real-time interaction while a separate service handles recording.

This separation is often easier to scale than making the media server responsible for everything.

Decision Framework: Which Architecture Should You Choose?

Don't start by asking, "Which WebRTC server should we use?"

Start with the product requirements.

1. How Many People Are in a Room?

If you're building:

1–2 participants

Start with Mesh unless you have a strong reason not to.

3–6 participants

Mesh can still work, but evaluate an SFU early if the product is expected to grow.

6–100+ interactive participants

An SFU is usually the most practical starting point.

Large audiences

Consider separating interactive participants from passive viewers using SFU + broadcast/CDN-style architecture.

2. How Important Is Server-Side Media Processing?

If you mainly need efficient routing, an SFU is attractive.

If you need server-side composition, mixing, or specialized media processing, an MCU or additional media-processing pipeline may make more sense.

3. What Is Your Budget?

Mesh minimizes media-server infrastructure but pushes bandwidth and processing requirements toward clients.

SFU requires server infrastructure but gives you much better control over bandwidth and scalability.

MCU typically requires the most compute-intensive infrastructure.

Don't compare architectures only by server count. Compare the total cost of bandwidth, compute, engineering, operations, and scaling.

4. How Fast Will the Product Grow?

This is where teams often make expensive mistakes.

If you're building a prototype for a two-person call, Mesh can be an excellent choice.

If you're building a product that you expect to grow from 10 to 10,000 concurrent users, design the architecture around the expected growth path rather than today's traffic.

Teams that need complete control over infrastructure, media routing, integrations, and scaling may eventually choose custom WebRTC development rather than depending entirely on a managed video platform.

The important point isn't that self-hosting is always better. It's that the architecture should match your cost model and product requirements.

Common Mistakes Teams Make

Choosing Mesh Because the Prototype Works

A two-person demo tells you almost nothing about how your application behaves with 20 participants.

Test realistic room sizes before committing to the topology.

Assuming an SFU Solves Everything

An SFU solves an important media distribution problem.

It doesn't automatically solve:

• Signaling
• Authentication
• TURN
• Recording
• Analytics
• Multi-region deployment
• Monitoring
• Capacity management

The surrounding platform still matters.

Ignoring TURN

WebRTC uses ICE to establish connectivity, but some users will be behind restrictive NATs, enterprise firewalls, or networks that prevent direct connectivity.

TURN provides a relay path when direct connectivity fails.

A production WebRTC system should treat TURN as core infrastructure rather than an optional debugging component.

Scaling Only the Media Server

Adding more SFU instances isn't enough.

You also need to consider:

• Room placement
• Signaling state
• Redis or another coordination layer
• Load balancing
• Regional routing
• Failover
• Metrics
• Network capacity

A media architecture is part of a larger distributed system.

Optimizing for Peak Participant Count Alone

"Can the server support 1,000 users?" is the wrong question.

Ask:

• How many rooms?
• How many publishers?
• How many subscribers?
• What resolution?
• Which codec?
• How many simulcast layers?
• How much screen sharing?
• What percentage of users are mobile?
• What regions are involved?

A 1,000-viewer broadcast and a 1,000-person interactive conference are completely different workloads.

Practical Next Steps

Before choosing Mesh, SFU, or MCU, write down your expected workload.

At minimum, define:

1. Maximum participants per room
2. Expected concurrent rooms
3. Video resolution and frame rate
4. Audio requirements
5. Screen-sharing requirements
6. Recording requirements
7. Expected geographic regions
8. Target latency
9. Mobile versus desktop traffic
10. Expected growth over 12–24 months

Then build a small load-testing environment.

Measure:

• CPU utilization
• Memory
• Network throughput
• Packet loss
• RTT
• Jitter
• Connection success rate
• End-to-end latency
• Stream subscription behavior

Don't rely entirely on theoretical capacity numbers.

Conclusion

Mesh, SFU, and MCU are not competing technologies where one architecture wins every time.

Mesh is simple and efficient for small peer-to-peer calls.

SFU is usually the strongest general-purpose architecture for scalable interactive conferencing.

MCU makes sense when centralized media processing and composition justify the additional infrastructure and CPU cost.

The most important decision is not choosing the architecture that handles the largest theoretical participant count. It's choosing the architecture that matches your actual media workload, product features, budget, and expected growth.

Start with measurable requirements. Prototype the media flow. Load-test realistic room sizes. Then choose the topology—and revisit the decision when the product requirements change.

That approach will save far more engineering time than trying to optimize a WebRTC architecture after you've already scaled past its original design.