The Scale Problem in Virtual Meetings

A virtual meeting for five people and a virtual meeting for 500 people are not the same problem. The infrastructure requirements, failure modes, and optimization strategies diverge significantly once you move beyond small group calls.

Most organizations discover this the wrong way: a critical all-hands call degrades under load, a product launch event fails mid-broadcast, or latency spikes during a training session that 300 employees are attending simultaneously. Efficient virtual meetings at scale are an infrastructure challenge before they are a product challenge.

What Determines Virtual Meeting Quality?

Quality Factor

Impact on Experience

Target Threshold

End-to-end latency

Conversational rhythm, interruption handling

< 150ms

Packet loss

Audio/video artifacts, freezing

< 0.5%

Jitter

Audio choppiness, lip sync drift

< 30ms

Bandwidth per participant

Video resolution and frame rate

1-4 Mbps (video)

Server capacity

Concurrent participant limits

Scale to demand

WebRTC as the Foundation

WebRTC (Web Real-Time Communication) is the open standard that powers most modern virtual meeting systems. It handles peer-to-peer media negotiation, NAT traversal through STUN and TURN servers, adaptive bitrate adjustment, and encrypted transport.

For small meetings (2-4 participants), peer-to-peer WebRTC is often sufficient. Each participant sends and receives streams directly from each other. As participant count grows, this model breaks down. A participant in a 20-person call cannot maintain 19 simultaneous sending streams without saturating their upstream bandwidth.

SFU Architecture for Scale

The selective forwarding unit (SFU) architecture solves the scale problem. Instead of each participant sending to every other participant, all streams are sent to a central SFU server, which selectively forwards the relevant streams to each participant.

With an SFU, each participant sends one upload stream (their own audio/video) and receives multiple download streams (other participants). The SFU can also apply bandwidth optimization by forwarding lower-resolution streams to participants on constrained connections.

•        Each participant uploads once regardless of meeting size

•        The SFU forwards only the streams each participant needs (active speaker, pinned video)

•        Server-side recording and processing become possible without client-side burden

•        Simulcast allows the SFU to select the appropriate resolution layer per receiver

Common Failure Points at Scale

Virtual meeting systems that work for 10 participants regularly fail at 100. The failure modes at scale are predictable:

TURN server saturation: When participants are behind symmetric NAT, media must relay through TURN servers. Undersized TURN infrastructure becomes the bottleneck that limits effective meeting size.

Signaling server congestion: Each participant joining triggers signaling messages. High join rates during large meetings create signaling server load spikes that delay connection setup and cause timeout cascades.

CPU bottlenecks in encoding: Video encoding is computationally expensive. Mobile participants with limited CPU headroom drop video quality or disable cameras under load, degrading meeting quality unpredictably.

Stop managing meetings Start automating outcomes

Build Your Virtual Infrastructure
CTA Illustration

Operational Best Practices for Large Virtual Meetings

•        Pre-test infrastructure with simulated load at 120% of expected peak participant count

•        Use region-specific TURN servers to minimize relay latency for geographically distributed attendees

•        Enable adaptive bitrate and simulcast by default; do not let participants manually lock to high resolution

•        Implement active speaker detection to reduce unnecessary stream forwarding to each participant

•        Monitor jitter and packet loss in real time with alerting thresholds, not just post-meeting reports