Topology atlas / seven lessons

One room. Seven ways to move the same pixels.

The topology is not a branding choice. It is a decision about who uploads, who forwards, who decodes, who can see the media, and who pays when the room gets larger. Read the seven shapes, run the numbers, then make the architecture argue for itself.

Read the atlas Test it in a lab LESSON 12

7 topologies/3 interactive tools/2 topology labs

Quick sanity checkn = 10 / 720p

Full mesh connections

n(n − 1) / 2 separate peer connections

Streams per mesh peer

9 up / 9 down

Every participant publishes to every other

SFU server egress

108 Mbps

If every subscriber receives every stream

The conclusion

Topology is a cost decision

The same ten people do not cost the same to connect

Numbers assume a 1.2 Mbps stream per direction. The calculator below uses your quality target and participant count.

n(n−1)/2

Mesh connections

Quadratic, before TURN

1 upload

SFU publisher

Selected streams back

n × B

Broadcast egress

Scales with the audience

01 / The seven shapes

A topology lesson for every way media can move.

Select a shape to read its working model, bandwidth math, trade-offs, and failure modes. The labels are deliberately concrete: what the client uploads, what the server forwards, and what a viewer actually downloads.

CLICK A TOPOLOGY. THE URL UPDATES WITH THE ANCHOR.

TOPOLOGY 01 / 072 people

Peer-to-peer

Two browsers, one negotiated path.

A single peer connection carries media and data directly between two participants. TURN may still relay the media when the network demands it, but there is no media server decoding or forwarding the session.

Room size: 2 people
Latency: Lowest
Client upload: Moderate
Client CPU: Moderate
Server cost: None
Complexity: Low

How it works

01
Each peer captures its local tracks and adds them to one RTCPeerConnection. Signaling exchanges a single offer and answer, then ICE discovers a pair and DTLS secures the transport.
02
Media is encoded once per sender and sent to the other browser. If the path is direct, no application server sees the media payload. If ICE selects a TURN relay, traffic is forwarded but not decoded.
03
The room service is still server-assisted: signaling, authorization, TURN credentials, and presence are control-plane responsibilities. The media path being peer-to-peer does not remove those services.
04
For a third participant, P2P stops being the topology and becomes mesh: every participant needs a connection to every other participant.

Bandwidth & cost math

Per-participant upload

One encoded stream, assuming one video and one audio track.

upload ≈ video bitrate + audio + overhead

Per-participant download

One stream from the other peer.

download ≈ remote video bitrate + audio + overhead

Server media egress

Zero for a direct path; TURN egress applies when the relay is selected.

TURN egress ≈ upload + download

Strengths

Lowest architectural latency: no media server hop in the direct path.
Simplest media-plane design and the cheapest to operate when paths are direct.
Natural fit for private conversations and the first milestone of any WebRTC product.
TURN remains a narrow, well-understood fallback for restrictive networks.

Limits

Does not scale beyond two participants without becoming mesh.
Connectivity depends on NAT/firewall conditions unless TURN is available.
No server-side recording, transcription, or moderation without adding a participant.
A peer can see the other peer's public network address unless relay-only privacy mode is used.

Use it when

A two-person customer support call.A private interview or telehealth conversation where recording is not required.A quick demo or internal tool with one remote guest.A fallback mode when SFU capacity is unavailable.

Do

Ship TURN with P2P: Direct connect is an outcome, not a guarantee. Without TURN, a meaningful share of real networks will fail.
Separate signaling from media health: A signaling reconnect should not tear down an established peer connection.
Offer relay-only privacy mode: If address privacy matters, use iceTransportPolicy: relay and verify the selected pair.

Don't

Don't call the whole product peer-to-peer: Signaling, TURN, rooms, and observability are server-side even when media is direct.
Don't add a third participant to P2P: That is mesh. Model the connection count and upload cost before the room grows.
Don't skip cleanup: Closing the connection is not enough; stop every local track and clear permissions UI state.

Reference implementations

Browser RTCPeerConnectioncoturnyour own WebSocket signaling

01 / 07

Now test the claim.

Compare the topology in the calculator, then watch the connection count grow in a lab.

Mesh lab SFU lab

02 / Side by side

Put them in one table.

No topology wins on every axis. Read across the row for the cost the architecture is asking you to own.

7 TOPOLOGIES / 8 DIMENSIONS

Topology	Room	Latency	Client up	Client CPU	Server cost	Privacy	Complexity
01P2P Two browsers, one negotiated path.	2 people	Lowest	Moderate	Moderate	None	Excellent	Low
02Mesh Everyone connects to everyone. Great for a small room; quadratic everywhere else.	3–6 people (practical)	Low	High	High	None	Excellent	Medium
03SFU One upload in, selected streams out. The default for interactive rooms.	5–100+ people	Low	Low	Low	Variable	Good	High
04MCU The server mixes everything into one program.	5–50 people	Higher	Low	Low	High	Server-visible	High
05Cascade Keep local media close, forward only what crosses regions.	50–500+ people	Moderate	Low	Low	Variable	Server-visible	High
06Broadcast One or a few publishers, a very large audience.	100s–100,000s of viewers	Low	Low	Low	High	Good	High
07Server peer Bots, recorders, captions, and AI join the room as peers.	Works alongside any topology	Moderate	Low	Low	Variable	Server-visible	High

Latency and cost are qualitative. Server cost includes media forwarding and egress, not signaling or storage. Client CPU depends on resolution, simulcast, and browser hardware acceleration.

Client upload

Mesh multiplies it. SFU/MCU keep one copy. Broadcast viewers send none.

Server cost

SFU scales with forwarded egress. MCU scales with decode/encode CPU. Broadcast scales linearly with viewers.

Privacy

Direct paths keep media off a server. A standard SFU terminates encryption at the server.

03 / Do the math

The curve is the argument.

For a mesh room, every participant encodes and sends one stream per other participant. Move the slider. The connection count grows on paper, but the product usually fails first on a single weak laptop's uplink and encoder count.

Participants in the room05

216

Video target

+64 kbps AUDIO / STREAM

Mesh connections

n(n − 1) / 2

4×

Streams per peer

Every peer, each direction

6.3 Mbps

Mesh uplink / peer

720p video + audio

31 Mbps

SFU server egress

If all subscribe to all

Per-participant uplink

Full mesh6.3 Mbps

SFU1.6 Mbps

MCU1.6 Mbps

The SFU/MCU sender still uploads one copy. The difference moves to the server's forwarding or mixing cost.

Aggregate media cost

Mesh · total client uplink31 Mbps

SFU · server egress31 Mbps

MCU · server egress11 Mbps

ASSUMES ONE 720P VIDEO + AUDIO STREAM PER DIRECTION. MCU COMPOSITE ESTIMATED AT 2.2 MBPS.

Mesh can work here, but test weak uplinks and older laptops.

If every mesh pair is relayed through TURN, relay traffic is roughly 13 Mbps per participant before signaling overhead.

RUN THE MESH LAB

04 / Decide deliberately

Start from the product, not the server.

Room size, publishing pattern, endpoints, and the dominant constraint. Four answers produce a direction and a runner-up, with the caveat that makes it honest.

1
Count publishers, not viewers
A thousand people watching one stage is a broadcast, not a mesh.
2
Name the device limit
A low-power endpoint may need a composite or a low simulcast layer.
3
Pick the cost you can own
Server egress, client uplink, CPU, and operational complexity are not the same currency.

Topology decision wizard

01 / 04

How many people are in the conversation?

Count active participants, not passive viewers. A viewer who never publishes is cheaper than a speaker.

05 / Where the cost lands

The same room, two different bills.

Mesh puts the curve on client uplinks. SFU puts it on server egress. MCU puts it on server CPUs. The chart is a conversation tool, not a capacity plan.

2–24 PARTICIPANTS / 1.2 MBPS STREAM

Scaling chart

One 1.2 Mbps video stream per direction. Selective subscription can reduce server egress.

MeshSFU / MCU

Inspect at8

2–24 PARTICIPANTS

Mesh: 8.4 Mbps
SFU / MCU: 1.2 Mbps

Mesh uplink grows with every extra person. SFU and MCU publishers keep one upload.

Now make it fail

A topology you have only read about is still a hypothesis.

Open the mesh lab to add simulated peers and watch the stream count grow. Then run the SFU lab to compare one-upload forwarding, selected layers, and server egress. The concepts only become yours when a connection breaks and you know which layer to inspect.

Mesh under load SFU relay lab READ LESSON 12