Group video calling is one of the harder real-time systems problems in consumer software, because unlike a chat message or a poll vote, video and audio cannot tolerate retransmission-based reliability — a lost packet in a video frame that arrives 300 ms late is worse than useless, it is discarded, because by the time it could be retransmitted the moment it was meant to capture has already passed. Everything about this system is shaped by that one constraint: it must move a continuous, high-bitrate stream of perishable data between many participants with latency low enough to preserve natural conversation, while participants join and leave at arbitrary, unpredictable moments without the other participants noticing anything worse than a brief visual blip.

1.1 A Brief Lineage

The technical lineage here runs from early point-to-point VoIP and video conferencing hardware (dedicated conference room systems in the 1990s and 2000s using proprietary protocols and specialized hardware codecs), through enterprise software conferencing bridges, to the modern era defined by WebRTC — an open, browser-native, standardized real-time media stack that Google open-sourced and pushed through W3C / IETF standardization starting around 2011. WebRTC is what made it possible for any messaging app to add “click a button, start a video call” without every participant installing a plugin or dedicated client, and it is the near-universal foundation underneath the group calling feature this document designs.

1.2 Why the “Simple” Requirement Is Actually Hard

The specific challenge in this brief — participants joining and leaving mid-call without disrupting others — is deceptively simple to state and genuinely difficult to build well. A two-person call has exactly one media path to manage. A group call with a changing participant count has to solve a combinatorial routing problem (who sends media to whom) that must be re-solved, quickly and invisibly, every time someone joins or leaves, all while the participants who did not change anything continue talking without a hiccup. Getting this wrong is not a subtle failure — it shows up immediately as a pop in someone’s audio or a frozen frame every time a colleague drops into a standing group call, and it is exactly the kind of defect that erodes trust in a messaging product’s calling feature faster than almost any other class of bug.

Two coupled sub-problems with different characters — a signaling problem (who is in the call, negotiating how each participant’s media connects) and a media transport problem (actually moving audio / video bytes with minimal latency). Keeping them separate is what makes the design legible.

2.1 Functional Requirements

2.2 Non-Functional Requirements

2.3 Sizing the Problem in Numbers

The architecture centers on a Selective Forwarding Unit (SFU) model — the industry-standard approach for group calls beyond a handful of participants — combined with a separate signaling layer that manages call membership and negotiation, decoupled from the media path itself.

3.1 Component Breakdown

4.1 WebRTC Fundamentals in This System

Each participant’s client uses WebRTC to establish a media connection to the SFU. The negotiation follows the standard offer / answer model (SDP — Session Description Protocol) to agree on codecs, encryption keys, and network paths, and ICE (Interactive Connectivity Establishment) to find the best actual network path between client and SFU, trying direct UDP connectivity first and falling back to a TURN relay if NAT / firewall traversal fails. All media is encrypted end-to-end between client and SFU using SRTP (Secure RTP), and typically further protected with DTLS for the key exchange itself.

4.2 Simulcast and Scalable Video Coding

A single participant’s outgoing video is rarely sent as just one quality stream. Using simulcast, a sending client encodes and uploads two or three simultaneous quality layers (e.g., low, medium, high resolution / bitrate) of its own video. The SFU then selectively forwards whichever layer is appropriate to each individual receiver, based on that receiver’s current bandwidth, CPU, and UI layout (a participant shown as a tiny thumbnail does not need the high-resolution layer; the currently-speaking participant shown full-screen does). This is the key mechanism that lets the same call gracefully serve receivers with wildly different network conditions without the sender needing to know or care about each receiver’s individual situation — the SFU makes that decision per-receiver, per-layer, continuously.

4.3 Selective Forwarding Logic

The SFU does not necessarily forward every participant’s stream to every other participant at full quality, especially as call size grows. Common optimizations include forwarding only the audio of participants who are actually currently speaking (audio-only or muted “silent” streams for everyone else, driven by voice-activity detection), and forwarding video only for a bounded number of currently-visible participants (e.g., an “active speaker” plus whoever is pinned / visible in the current UI layout) rather than every single participant’s video to every single receiver — turning what would otherwise be O(N²) total forwarding work into something closer to O(N × visible_tiles), a materially better scaling shape for larger calls.

4.4 Codec Selection and Adaptation

Codec choice affects both quality-per-bit and CPU cost — modern deployments typically negotiate a codec like VP8 / VP9 or H.264 for broad compatibility, with newer, more bandwidth-efficient codecs like AV1 used where both ends support it. Because the SFU never decodes or re-encodes media in the selective-forwarding model, codec negotiation happens once per sender-receiver pair at connection time and stays fixed for that pair’s session — the SFU is simply forwarding whatever bytes it receives, agnostic to the codec inside them, which is part of why it is so much cheaper computationally than an MCU.

4.5 Congestion Control and Bandwidth Estimation

Each WebRTC connection continuously estimates available bandwidth (commonly via Google Congestion Control or similar algorithms built into the WebRTC stack) using signals like packet loss, delay, and jitter observed on that specific path. The sender uses this estimate to decide which simulcast layers to keep sending and at what encoded bitrate; the SFU uses its own per-receiver bandwidth estimate to decide which of the sender’s available layers to actually forward to that receiver. This dual-sided estimation — sender deciding what to produce, SFU deciding what to relay per receiver — is what allows the same call to serve a participant on gigabit fiber and a participant on a spotty 4G connection simultaneously, each getting a stream matched to their own real-time conditions.

4.6 Packet Loss Concealment and Jitter Buffering

Because retransmission is often not viable for real-time media (a retransmitted packet frequently arrives too late to be useful), receivers rely on loss-tolerant techniques: forward error correction (sending modest redundant data that allows reconstructing some lost packets without retransmission), packet loss concealment (audio codecs like Opus can synthesize a plausible continuation of speech across small gaps), and jitter buffers (a small, adaptive buffer on the receiving end that absorbs variable network delay and smooths playback, at the cost of a small amount of added latency). None of these live at the SFU — they are endpoint (sender / receiver) responsibilities — but the SFU’s job of forwarding packets promptly and without adding its own significant queuing delay is what keeps these endpoint mechanisms effective.

The join and leave flows follow the same underlying principle: the SFU changes the set of forwarded streams without disturbing anyone else’s active connection.

The crucial detail is that existing participants’ own WebRTC connections to the SFU are not torn down or renegotiated when a new participant joins — the SFU simply begins forwarding an additional inbound stream to them (using modern WebRTC capabilities like a single negotiated transceiver that can carry a dynamic set of streams, or lightweight, non-disruptive renegotiation that does not interrupt existing media flow). This is precisely what prevents a join from being disruptive to people already on the call.

A distinction worth calling out explicitly: a graceful leave (user taps “leave call”) and an ungraceful disconnect (network drop, app crash) are detected differently — the former is an explicit signaling message, the latter is inferred via WebRTC connection-state changes and / or a heartbeat timeout — but both converge on the same cleanup path once detected.

This is the heart of the brief, so it is worth pulling the relevant mechanisms together explicitly rather than leaving them scattered across other sections.

6.1 Why Naive Approaches Break

A naive implementation might treat any membership change as “renegotiate the whole call” — tear down and rebuild the SDP / ICE session for every participant whenever anyone joins or leaves, since the “set of streams in the room” technically changed. This causes a visible / audible glitch (a brief black frame or audio pop) for every existing participant, every single time anyone else joins or leaves — clearly unacceptable for a group call in an active messaging app where people join and leave frequently.

6.2 The Fix: Decouple “Connection” from “Stream Set”

The mechanism that solves this is treating each participant’s WebRTC connection to the SFU as a stable, long-lived transport session whose set of actively flowing streams can change dynamically without renegotiating the underlying connection itself. Modern WebRTC (via the Unified Plan SDP semantics and dynamically added / removed transceivers, or an SFU’s proprietary lightweight signaling for stream subscription) supports adding or removing a forwarded stream to / from an existing peer connection without a full renegotiation round-trip — this is what allows the SFU to start or stop forwarding one participant’s media to another without disturbing anyone’s actual connection state.

6.3 Client-Side Smoothing

Beyond the transport-layer mechanism, the client UI itself absorbs churn gracefully: a joining participant’s video tile fades in once their stream stabilizes (rather than popping in mid-frame), a leaving participant’s tile is removed with a short transition, and the audio mixer applies a brief fade rather than an abrupt cut when a stream stops, so a leave does not sound like a click or pop in other participants’ ears.

6.4 Late-Joiner Bootstrap

A participant joining a call already in progress needs to quickly reach the current state of every other stream (video keyframes in particular — video decoding cannot start mid-frame). The SFU forces a fresh keyframe request to each existing sender specifically for the benefit of the new joiner (existing participants’ own decode state is unaffected, since they are still receiving whatever cadence of keyframes they were already getting) — this is a small, per-join server-side action that has no visible impact on anyone already in the call, but is what makes a new joiner’s video “snap in” quickly rather than showing a gray box for a few seconds.

6.5 Renegotiation Batching Under High Churn

In a large call where several participants join or leave within the same short window (e.g., a scheduled meeting starting, where a dozen people click join within a few seconds of each other), the orchestrator batches the resulting stream-set updates pushed to the SFU rather than processing and pushing an individual update per event — reducing the total number of small control messages and avoiding any risk of the SFU thrashing its forwarding tables under a burst of near-simultaneous membership changes.

No single architectural choice here is free — every decision that makes join / leave graceful, or that makes the system scale to larger calls, trades away some simplicity, some cost, or some flexibility elsewhere. Laying these out explicitly is often exactly what separates a design that merely works from one that demonstrates real engineering judgment in an interview setting.

8.1 Bandwidth Scaling Comparison

The SFU model shifts the quadratic cost from clients’ scarce, asymmetric consumer upload bandwidth onto server infrastructure that can be horizontally scaled and is typically running on well-provisioned data center network links — which is precisely why it is the standard choice once group size exceeds what mesh can handle.

8.2 SFU Node Capacity Planning

A single SFU node’s capacity is bounded primarily by aggregate throughput (total Mbps of forwarding across all its hosted calls) and, secondarily, CPU for packet handling, RTCP processing, and simulcast layer selection logic. For calls exceeding a single node’s comfortable capacity (either one very large call, or many concurrent smaller calls), the cluster router distributes calls across nodes, and for a single call that is unusually large, participants can be split across multiple SFU nodes with an inter-node relay path forwarding between them — trading a small amount of extra latency for that cross-node hop against the ability to scale a single call beyond one machine’s limits.

8.3 Geographic Routing

The call orchestrator prefers assigning a call to the SFU node geographically closest to the majority of its participants (or, for a call whose participants are globally spread, potentially splitting across regional nodes) to minimize the median round-trip time, since latency for real-time media is a direct, felt quality factor rather than an abstract metric.

8.4 Concrete Capacity Example

Consider a single SFU node comfortably handling an aggregate forwarding throughput of roughly 2–3 Gbps. A mix of concurrent calls averaging 8 active participants each, with active-speaker-limited forwarding keeping each participant’s download to roughly 4 visible streams at medium quality (~500 kbps each, ~2 Mbps download per participant), works out to roughly 16 Mbps aggregate forwarding per 8-person call — meaning a single node could theoretically host on the order of 150–180 such calls concurrently before hitting the bandwidth ceiling, well before CPU typically becomes the binding constraint for straightforward forwarding (as opposed to any server-side compositing or transcoding, which would shift the bottleneck to CPU / GPU much sooner). Real deployments target meaningfully below this theoretical ceiling to preserve headroom for uneven load distribution and traffic spikes.

8.5 Cost of Non-Disruptive Join / Leave vs. Naive Renegotiation

It is worth quantifying why the non-renegotiating approach matters at scale, not just for UX polish: a full SDP renegotiation round-trip typically costs on the order of one to a few hundred milliseconds of signaling round-trip time, plus the encoder / decoder pipeline reset that causes the visible glitch. In a call with frequent organic churn — say, an average of one join or leave every 30 seconds sustained over a long-running call — naive renegotiation-on-every-change would impose that glitch on every existing participant roughly twice a minute, which very quickly becomes the single most complained-about aspect of the product. The non-renegotiating stream-set-update approach reduces the existing-participant-facing cost of each churn event to effectively zero, at the one-time architectural cost of building and maintaining the more sophisticated dynamic stream-subscription mechanism.

9.1 Failover Runbook, Conceptually

1. Clients detect connection loss to their SFU node via WebRTC connection-state change events (ICE connection state transitioning to “failed” or “disconnected” beyond a grace period).
2. The signaling layer is separately notified (via health checks or the same connection-loss signal relayed through the client) and marks the affected SFU node unhealthy, triggering the orchestrator to select a replacement node.
3. Call membership and each participant’s last-known state (mute status, active layout) are read from the replicated call state store — unaffected by the SFU node failure since they were never stored there.
4. Each affected client re-establishes a fresh WebRTC connection to the new node, following essentially the same flow as an initial join.
5. Once all affected clients have reconnected, normal forwarding resumes; unaffected calls on other, healthy nodes experience zero impact throughout.

The total user-visible interruption is bounded by connection-loss detection time plus reconnection time — typically a handful of seconds — versus the alternative of the entire call simply ending, which is why this failover path is considered a core reliability requirement rather than a nice-to-have.

10.1 Threat Model Summary

11.1 Example SLOs

12.1 Cost Considerations

Media server capacity (SFU nodes) is the dominant infrastructure cost for this feature, scaling roughly with aggregate concurrent call-minutes and average call size, not with total registered users — a platform with millions of users but modest concurrent call volume has a very different cost profile than one where video calling is the primary activity. TURN relay usage is a secondary but non-trivial cost driver, since a meaningful fraction of real-world connections (commonly cited industry figures put it at somewhere around 10–20% of sessions) require relaying rather than direct connectivity, and relayed media consumes real server bandwidth for the call’s full duration. Because both costs scale with usage rather than with a fixed infrastructure footprint, capacity planning and forecasting tie closely to product growth projections for the calling feature specifically, not just overall platform growth.

12.2 Multi-Region and Data Residency

For a global messaging platform, SFU placement also has to account for data residency requirements in some jurisdictions (media, and particularly recordings, may need to stay within a specific region’s infrastructure for regulatory reasons), which constrains the otherwise purely latency-driven geographic routing logic with an additional compliance-driven placement rule layered on top.

Load balancing for the signaling tier is standard L4 / L7 balancing across stateless nodes. Load balancing for the media tier is a fundamentally different problem — it is really a placement decision (which SFU node should host this call) made once at call-start / first-join time by the orchestrator, based on geography and current node load, rather than a per-request balancing decision, since a call’s media path needs to stay pinned to a consistent node (or fixed set of nodes) for the call’s duration.

15.1 Patterns Used

15.2 Anti-patterns to Avoid

The SFU-centric, control-plane / data-plane-separated architecture described here is the dominant pattern across the industry’s group calling products, converging from the same underlying constraints rather than any one company’s specific implementation.

Taken together, the join / leave-specific mechanisms — non-renegotiating stream add / remove, forced keyframes for new joiners, and client-side smoothing — are what turn a generically scalable media architecture into one that specifically satisfies this brief’s core requirement: participants coming and going should be an ordinary, unremarkable part of a live call, not an event anyone else even notices. The broader lesson generalizes well beyond video calling: whenever a system’s steady-state behavior is easy but its membership-change or state-transition behavior is hard, that transition path deserves the same deliberate architectural attention as the steady state itself, rather than being treated as an edge case bolted on after the fact.