SFU vs MCU vs Mesh WebRTC Architecture: Production Guide | Betadrix

The first architectural decision in any WebRTC project is topology. Choose wrong, and your video call collapses at five participants. Choose right, and you scale to thousands without breaking your infrastructure budget.

Engineering teams face radically different constraints depending on where their users live. A telemedicine platform serving San Francisco runs on fiber with sub-200ms latency requirements and HIPAA audit trails. An ed-tech classroom app serving Tehran runs on 1–3 Mbps DSL uploads, mobile-heavy usage, and strict cost sensitivity. Both need the same fundamental decision: Mesh, MCU, or SFU? This guide compares all three across bandwidth, CPU, latency, and real-world scalability — with production thresholds drawn from architecture reviews of systems handling 8,000–12,000 concurrent sessions.

Quick Decision Matrix

Use this matrix as a starting point. The sections below explain the engineering behind each threshold.

Why Topology Is the Make-or-Break Decision

Before writing signaling code, decide how media flows between participants. This impacts:

• Client upload bandwidth — often the hardest constraint
• Server infrastructure cost — CPU-bound (MCU) vs. bandwidth-bound (SFU)
• End-to-end latency — critical for interactive telemedicine and financial KYC
• Compliance and recording — whether you need individual stream audit trails or composite archives

Everything else — codec selection, TURN placement, and latency optimization — follows from this choice.

Mesh (P2P): Simple, But Brutally Limited

In Mesh, every participant sends audio and video directly to every other participant. No central media server. With 4 participants, each peer maintains 3 peer connections and 3 independent outbound encodes.

Bandwidth Math

At 1.5 Mbps per video stream:

• 3 participants: 3 Mbps upload per peer
• 4 participants: 4.5 Mbps upload per peer
• 6 participants: 7.5 Mbps upload per peer

Upload bandwidth grows quadratically. Most consumer connections offer 5–10 Mbps upstream. Mesh collapses not from CPU, but from network interface saturation. Packets drop. Frames freeze.

When Mesh Makes Sense

• 1:1 video calls
• Small standups (≤3 people)
• Privacy-critical apps where no server may touch media
• Prototypes validating signaling before media server investment

MCU (Multipoint Control Unit): The Heavy Lifter

An MCU receives every stream, decodes it, composites a layout, re-encodes, and sends one unified stream back.

Advantages

• Minimal client bandwidth — one stream in, one stream out
• Legacy SIP and hardware endpoint compatibility
• Trivial server-side recording with guaranteed A/V sync

Disadvantages

• Massive CPU load: Real-time decode-mix-encode burns 1–1.5 vCPU cores per publisher
• High latency: 150–400 ms added end-to-end
• Hard to scale horizontally: Rooms shard by node; popular rooms create hotspots

Production Thresholds

SFU (Selective Forwarding Unit): The Production Default

An SFU receives one stream per participant and selectively forwards appropriate layers to each recipient. It does not transcode, so CPU stays low.

Simulcast

The publisher sends multiple quality layers. The SFU forwards HD to the active speaker on fiber, and a 250 Kbps thumbnail to the mobile peer on 3G. Chrome and Safari support simulcast natively; mobile implementations require careful encoder tuning.

// Browser simulcast configuration (VP8/VP9)
const params = sender.getParameters();
params.encodings = [
  { rid: 'h', maxBitrate: 2500000, scaleResolutionDownBy: 1 },  // HD
  { rid: 'm', maxBitrate: 1000000, scaleResolutionDownBy: 2 },  // SD
  { rid: 'l', maxBitrate: 250000,  scaleResolutionDownBy: 4 }   // Low
];
await sender.setParameters(params);

SVC (Scalable Video Coding)

VP9 and AV1 encode temporal and spatial layers into a single stream. The SFU drops layers on the fly without transcoding. H.264 does not support SVC, which limits adaptive bitrate on legacy codecs.

Production Thresholds

Head-to-Head Comparison

SFU dominates for multi-party interactive video. MCU survives only for legacy endpoints or extreme bandwidth constraints. Mesh is a cost-saving tool for 1:1 calls.

Hybrid Architectures

Pure topologies rarely survive production. Successful platforms combine them with clear switching rules.

P2P → SFU Switching

Start 1:1 in Mesh. When a third peer joins, migrate to SFU via ICE restart. This defers infrastructure cost until the conversation generates value.

SFU + MCU Cascade

Route interactive speakers through SFU for low latency, then pipe to an MCU for broadcast to passive viewers. In Mediasoup, this looks like:

// Pipe producer from SFU router to MCU broadcast router
await pipeToRouter({
  producer,
  router: broadcastRouter,
  listenIp: '0.0.0.0'
});

Decision Rules

• Room size ≤ 2 → Mesh
• Room size 3–8 + strict mobile bandwidth → MCU
• Room size 3–100 + mixed networks → SFU
• Room size 100+ with few speakers → SFU + MCU cascade

Cost Modeling

These are rough AWS c6i estimates. Actual costs vary by region, egress pricing, codec efficiency, and simulcast layer distribution. A VP9 SVC stream at 1 Mbps costs less than an H.264 simulcast stack at 2.5 Mbps. Design your bitrate ladder before provisioning infrastructure.

Disclaimer: Figures are directional only. Run your own load tests on target infrastructure before committing to budget.

Failure-Mode Monitoring

Watch these signals in production:

• ICE failure rate > 5% → Check TURN credentials and STUN reachability
• RTT > 250 ms sustained → Switch to TURN relay or drop simulcast layer
• MCU CPU > 75% → Cap new publishers or spill to secondary node
• SFU NIC utilization > 70% → Horizontal scale (new node)
• Packet loss > 2% → Trigger TWCC/REMB downscale immediately
• Audio energy but zero RTP → Encoder failure; restart producer

Deployment Context: Bandwidth Reality

Network constraints are not theoretical. In markets with fiber-rich infrastructure, Mesh reaches its 4-participant limit before bandwidth becomes the bottleneck. In markets where residential DSL offers 1–3 Mbps upstream, Mesh dies at 2–3 peers. MCU becomes attractive for mobile endpoints on constrained networks because it sends exactly one stream. SFU with aggressive simulcast (250 Kbps low layer) bridges both worlds, but requires robust cloud infrastructure to manage bandwidth costs.

Technology Stack Notes

Your topology constrains server selection:

• Mediasoup: SFU-first, Node.js/Rust/C++ core. Excellent for custom routing and simulcast control.
• Janus: Plugin-based. Supports SFU, MCU, and recording. Good for hybrid setups.
• Jitsi Videobridge: SFU optimized for Meet-style conferences.
• Pion: Pure Go. Lightweight embedding into existing backends.

See the Mediasoup documentation and WebRTC.org overview for protocol-level details. For production implementation, our engineering team provides security hardening and full-stack integration.

Common Architecture Mistakes

1. Ignoring TURN bandwidth: Budget 30% of total media volume for relay.
2. Static bitrates: Networks fluctuate. React to TWCC/REMB within 200 ms.
3. Undersized SFU instances: SFU is bandwidth-bound. Use high-ENA instances (c6i.2xlarge+).
4. Wrong codec for SVC: H.264 lacks SVC. Use VP9 or AV1 if layer dropping is required.
5. No graceful degradation: Drop resolution before frame rate. Pixelation beats stutter.

Architecture Decision Checklist

• □ Max participants per room? Mesh (≤2), MCU (≤8), SFU (3–100), Hybrid (100+)
• □ Minimum user upload bandwidth? Mesh needs 3+ Mbps per peer; MCU/SFU need <1 Mbps
• □ Latency budget? <200 ms → SFU; <500 ms → MCU acceptable; any → Mesh
• □ Server-side recording required? Individual streams → SFU; composite → MCU; none → Mesh
• □ Legacy SIP endpoints? Yes → MCU; No → SFU
• □ Compliance / audit trails? HIPAA/SOC 2 → SFU with individual stream recording

Conclusion

Mesh is a teaching tool, not a production topology for groups. MCU solves niche bandwidth-constraint problems at the cost of latency and server overhead. SFU is the industry default because it balances scale, latency, and flexibility.

The best architectures are hybrid: start in P2P, migrate to SFU as rooms grow, and cascade to MCU only when broadcasting to passive audiences. Measure bandwidth and CPU at every threshold. Test on real networks. And place TURN infrastructure close to your users.