Reduce subscriptions
Paginate video, pause off-screen consumers, and avoid forwarding tracks that cannot affect the experience.
Capacity planning
Scale WebRTC by controlling subscriptions, quality, workers, and regions.
WebRTC scale is not a single participant limit. It is the combined load from producers, subscribed consumers, bitrate layers, recording egress, AI media, and regional network paths. Control those variables first, then distribute rooms across workers and regions.
4primary capacity variables
3common simulcast layers
1room ownership boundary
Selective media flowPublish once. Route by need.
ClientsAudio, video, screen
→SFUSelect and forward
→OutputsClients, recording, AI
Signaling controls the session. Secure WebRTC transports carry media. The SFU forwards the streams and quality layers each receiver needs.
Decision 01
Treat room scale and platform scale as different problems
A large room needs selective subscriptions and presentation rules. A large platform needs room placement, worker health, regional routing, and failure recovery.
| Topology | Best fit | Main tradeoff | Media control |
|---|---|---|---|
| P2P | One-to-one calls and very small sessions | Each participant sends media to every other participant | Application-owned |
| SFU | Interactive rooms, broadcasts, recording, and real-time AI | Requires server routing, capacity planning, and observability | Server selects and forwards streams |
| MCU | A single precomposed output or legacy endpoints | Server decodes and mixes media, increasing compute cost | Server composes the final stream |
System view
The SFU is the routing core, not the whole product.
Adapt bitrate
Use quality layers and receiver conditions instead of sending the largest stream to every participant.
Distribute rooms
Place room ownership on healthy workers and route users to regions with suitable latency and capacity.
Decision 02
Move from topology to a production plan.
The useful sequence is workload, ownership, media path, and proof. Starting with a UI framework skips the decisions that determine reliability and cost.
- 01
Measure the workload
Track producer count, active consumers, aggregate bitrate, CPU, memory, and transport health.
- 02
Bound the room
Set participant, producer, page-size, resolution, and recording limits appropriate to the use case.
- 03
Spread ownership
Assign rooms to workers and regions without splitting one room across infrastructure unnecessarily.
- 04
Design recovery
Use health checks, idempotent signaling, reconnect behavior, and observable placement decisions.
Implementation ownership
Know what you are adopting.
mediasoup is an independent, signaling-agnostic open-source SFU. MediaSFU builds a managed platform around that routing foundation; it does not rename the upstream project or erase the responsibilities your application still owns.
Read the official mediasoup overview- Room and event APIs
- Web, mobile, native, and Unity SDK paths
- Prebuilt UI, widgets, and headless controls
- Recording, telephony, translation, and AI media workflows
- Regional infrastructure and operational tooling
Questions engineers ask
Short answers before you choose the stack.
What determines WebRTC SFU capacity?
Producer bitrate, consumer subscriptions, quality layers, packet processing, recording or AI egress, and network capacity all contribute. Participant count alone is incomplete.
Does pagination actually reduce load?
Yes, when off-screen video consumers are paused or not created. Merely hiding video with CSS does not stop media delivery.
Should one room span multiple SFU workers?
Keeping room ownership together is simpler when capacity permits. Very large workloads may need specialized distribution, but it adds routing and synchronization complexity.
Continue the decision
Open the guide for the next constraint.
Build after the architecture is clear