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.
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




