Skip to content
On this pageOPEN
  1. 01Goal
  2. 02Plain-language concept
  3. 03Interactive diagram
  4. 04Behind the scenes
  5. 05Code walkthrough
  6. 06Do & don't
  7. 07Practice
  8. 08Quick quiz
  9. 09Key takeaways
  10. 10Common errors
LESSON 12Advanced55 min read

WebRTC topologies at scale

P2P, mesh, SFU, MCU, cascaded SFUs, broadcast, and server-side participants, with the math behind each choice.

#SFU#MCU#mesh#cascading#WHIP#WHEP
01

Goal

  • 01Choose among P2P, mesh, SFU, MCU, cascaded SFU, broadcast, and server-side participant topologies for a real room size.
  • 02Estimate upload, download, server egress, and CPU before the architecture makes the decision for you.
  • 03Explain why an SFU is the default for interactive multi-party video and when it is still the wrong answer.
02

The concept, plainly

**P2P** is one connection between two peers. Each uploads one stream and downloads one. It has the lowest server cost and, when the path is direct, the lowest latency. It is the correct starting point for a 1:1 call and a poor fit for a large room. **Mesh** connects every participant to every other participant. Each peer encodes and uploads `n − 1` streams and receives `n − 1`. Upload bandwidth, CPU, and the number of peer connections grow quadratically. Mesh is useful for small, temporary groups where privacy and server independence matter more than scale.

**SFU** (Selective Forwarding Unit) receives one stream per publisher and forwards selected streams to subscribers. Each client uploads roughly one copy, but the server's egress grows with the number of subscribers and the SFU must route, adapt, and often simulcast. It is the default for interactive rooms because it scales much further than mesh while preserving per-participant streams. It is not free: you need TURN-like capacity, regional routing, and a media server operator.

**MCU** (Multipoint Control Unit) decodes incoming media, mixes it into a composite, and re-encodes one or a few outputs. Each client uploads one stream and downloads one composite, which is excellent for constrained downlinks. The server bears heavy CPU and the product loses per-participant layout and some control. Latency is usually higher, and mixing can reduce quality or accessibility. It fits broadcasting-style meetings and low-bandwidth endpoints, not low-latency interactive apps.

**Cascaded SFUs** connect SFUs across regions or large rooms, forwarding selected streams between servers. This reduces cross-region egress and keeps local participants close to a local media server, at the cost of inter-SFU delay and a routing hierarchy. **Broadcast** is a one-to-many topology: one or a few publishers, many subscribers, often through an SFU or a streaming/CDN path. Upload is low for viewers, but interactivity is limited. **Server-side participant** is a bot, recorder, translator, or transcriber that joins as another peer; it consumes server media capacity and needs clear lifecycle and consent.

Start with the room size and the product's interactivity. A 1:1 call: P2P with TURN fallback. A 3–6 person standup: mesh can work on good networks, but SFU is already easier to operate consistently. A 10–100 person meeting: SFU with simulcast and active-speaker subscriptions. A webinar for thousands: broadcast/SFU with selective subscription and a CDN path, not full mesh. Recordings, captions, and AI participants are server-side participants, not magic free features.

03

See it move

PLAY / PAUSE / STEP

Interactive diagram

Where the copies multiply

add peersstop full copiesmix at serverscale regionsfan outCPU + mediabudgetPEERP2P1 upload · 1 downloadNETWORKMeshn−1 up · n−1 downSERVERSFU1 up · selective downSERVERMCUmix + re-encodeSERVERCascaded SFUsregional forwardingNETWORKBroadcastone → manyPROCESSServer-side peerbot / recorder / AISTORAGECost curveO(n²) → O(n)BROWSERProduct decisioninteractivity × room size
STEP 01 / 08n = 2

Start with one peer

A 1:1 call is the simplest topology and should not pay for a media server unless the path or the product needs one. TURN still belongs in the design.

The topology decides who uploads, who forwards, who mixes, and where server cost lands.

04

Behind the scenes

01

SFU is not a peer connection

An SFU is a media server that terminates DTLS-SRTP with each participant and makes forwarding decisions. It usually does not decode media. That makes it cheaper than an MCU for many interactive streams, but it still has significant egress and signaling work. 'SFU' also does not mean 'no TURN'; the server itself is the relay path for media, and signaling still needs a control plane.

02

The n² shows up in different places

In mesh, the client pays: more encodes, more uploads, more connections. In SFU, the server pays: more subscribers, more forwarded streams, more egress. In MCU, the server pays CPU. In broadcast, the egress pays for scale. A topology comparison that only counts server dollars misses client battery, thermal limits, and bandwidth caps.

03

Selective subscription is the real SFU feature

Sending every participant's highest-quality stream to every subscriber turns an SFU into an expensive mesh. Active-speaker detection, pinned participants, simulcast layer choice, and dropping video for audio-only viewers keep cost and bandwidth bounded. Design the subscription policy before the room grows.

05

Code walkthrough

COPY-READY

These estimates assume one video stream per participant and ignore headers, retransmissions, and audio. Use them to reject a topology early, not to size production capacity exactly.

lib/topology-math.ts
export function meshStreams(peers: number) {
  return {
    connections: (peers * (peers - 1)) / 2,
    uploadsPerPeer: Math.max(0, peers - 1),
    downloadsPerPeer: Math.max(0, peers - 1),
    totalDirectionalStreams: peers * (peers - 1),
  };
}


export function bandwidthMbps(
  peers: number,
  videoKbpsPerStream: number,
  topology: "mesh" | "sfu" | "mcu" | "broadcast",
) {
  const mbps = videoKbpsPerStream / 1000;
  if (topology === "mesh") {
    return {
      perClientUp: (peers - 1) * mbps,
      perClientDown: (peers - 1) * mbps,
      serverEgress: 0,
    };
  }
  if (topology === "sfu") {
    return { perClientUp: mbps, perClientDown: (peers - 1) * mbps, serverEgress: peers * (peers - 1) * mbps };
  }
  if (topology === "mcu") {
    return { perClientUp: mbps, perClientDown: mbps, serverEgress: peers * mbps };
  }
  return { perClientUp: 0, perClientDown: mbps, serverEgress: peers * mbps };
}
06

Do and don't

Do

  • Start from room size and interactivity

    The number of active speakers and the need for per-person layout matter more than a generic preference for SFU or mesh.

  • Measure both client and server cost

    Mesh taxes uploads and CPU; SFU taxes server egress; MCU taxes server CPUs. Include devices and support in the decision.

  • Design subscription rules early

    Active speaker, pinned participant, simulcast layer, and audio-only fallback keep SFU egress controllable.

  • Load test with realistic networks

    Ten laptops on an office LAN are not a load test. Add packet loss, mobile devices, and a relay-only path.

Don't

  • Don't use mesh for a large room

    The n−1 uploads and encodes per participant become untenable. Mesh is a small-room tool, not a scale strategy.

  • Don't call every SFU deployment scalable

    Without selective subscription, simulcast, and regional capacity, an SFU can still burn bandwidth and fall over.

  • Don't promise E2EE with a standard SFU

    Terminating DTLS-SRTP at the server means the server can see media. E2EE requires a separate design.

  • Don't treat bots as free

    Recording, captions, and AI participants join as media consumers and may add decode, storage, and consent obligations.

07

Practice

Hands-on lab

Feel the topology cost

Open the mesh lab in one tab and add simulated peers. Watch the number of peer connections, streams, and estimated bandwidth grow. Then compare with the SFU simulation.

  1. 1Start with two participants and add peers one at a time.
  2. 2Record connections, uploads per peer, and total directional streams at four and six peers.
  3. 3Switch the topology page to SFU and compare client upload versus server egress.
  4. 4Use the decision wizard for a 12-person standup and a 2,000-person webinar and defend the results.
Open the mesh lab

Solo? The topology page includes a mesh calculator and decision wizard. Use the math even if you cannot open multiple camera tabs.

08

Quick quiz

Knowledge check

0 of 5 answered

0%
  1. 01

    In a mesh of n peers, how many streams does each peer upload?

  2. 02

    What does an SFU forward?

  3. 03

    Which topology best fits a 2,000-person webinar with a few presenters?

  4. 04

    Why is an MCU's client downlink lower than an SFU's in a large meeting?

  5. 05

    Which statement about SFU encryption is accurate?

Pick one answer per question to see instant feedback.
09

Key takeaways

  1. P2P is for two peers; mesh grows uploads, CPU, and connections as n−1 per participant.01
  2. An SFU centralizes forwarding and is the default for interactive multi-party rooms, but server egress and subscription policy matter.02
  3. An MCU trades server CPU for low client downlink and simpler composite outputs.03
  4. Cascading, broadcast, and server-side participants are scaling and product decisions, not free add-ons.04
10

Common errors and fixes

Terms in this lesson

SFUMCUMeshP2PCascaded SFUWHIPWHEPSimulcast

Done with this lesson?

Mark it complete, then keep the thread.

PREVIOUS

Network quality & getStats

NEXT

Security & privacy