Video conferencing feels ordinary today — you click a link and you are looking at a colleague’s face in under two seconds. But underneath that simplicity is one of the hardest problems in distributed systems: moving audio and video, in real time, between potentially thousands of devices, over unreliable networks, with a latency budget so tight that anything above roughly 150 to 200 milliseconds one-way starts to feel “off” to a human brain.

The problem we are solving in this tutorial is specific and hard: design a video conferencing system that can host a single meeting with up to 1,000 simultaneous participants, while keeping audio and video quality “acceptable.” That last word matters — at 1,000 participants, no system on Earth sends everyone’s full-resolution video to everyone else. The entire design challenge is about intelligently deciding who sees what, at what quality, and why.

1.1 A Brief History of Video Conferencing

1.2 What Makes This Problem Hard

Most system design interviews ask you to scale something that tolerates delay — a feed, a search index, a payment ledger. Video conferencing is the opposite: every packet has an expiration date measured in milliseconds. A video frame that arrives two seconds late is not “eventually consistent,” it is simply useless and gets thrown away. This single constraint reshapes every decision in the system.

With that framing, the 1,000-participant requirement is not really “make everything 1,000 times bigger.” It is “figure out which 1 percent of the naive design actually needs to scale to 1,000, and make everything else scale sub-linearly or not at all.”

1.3 Functional and Non-Functional Requirements

Functional Requirements

• Users can create, schedule, and join meetings, with role-based permissions (host, co-host, panelist, attendee).
• Meetings support live audio and video from participants, up to 1,000 concurrent participants in a single meeting.
• Participants can mute/unmute audio, enable/disable video, share their screen, and send chat messages or reactions.
• The system supports active-speaker highlighting, pinning, and grid/gallery views.
• Meetings can optionally be recorded and later played back or transcribed.
• Hosts can manage participants — mute all, remove a participant, lock the meeting, move participants to breakout rooms.

Non-Functional Requirements

1.4 Back-of-the-Envelope Capacity Estimation

It is worth sizing the problem before designing the solution, the way you would in a real interview.

• Assume a platform running many concurrent meetings, with a handful of “mega meetings” (500 to 1,000 participants) happening at any given time across the fleet, alongside a much larger number of small meetings (2 to 20 participants).
• Video-on ratio: in a realistic 1,000-person town hall, perhaps 5 to 10 panelists or hosts have cameras on continuously, and a long tail of attendees keep cameras off most of the time — this ratio is the single biggest lever on required capacity.
• Forwarded streams, not raw participants, drive cost. If 10 people publish video and the system forwards each of those to, say, 50 visible viewers on average (grid pagination caps what is visible), that is roughly 500 forwarded video subscriptions for that meeting — orders of magnitude less than a naive 1,000 × 1,000 full mesh.
• Audio is comparatively cheap. Even forwarding audio for all 1,000 participants (muted participants send nothing) costs only tens of kbps per active speaker, so audio scaling is rarely the bottleneck — video fan-out is.

This estimation exercise is exactly why the rest of this document keeps returning to one idea: bound the number of forwarded video streams, not the number of participants.

At a high level, a video conferencing platform is really three systems bolted together: a signaling plane (who is in the meeting, and how do peers agree to exchange media), a media plane (the actual audio and video packets, optimized for real-time delivery, not durability), and a control plane (meeting scheduling, authentication, recording, chat, and the web and mobile apps that tie it together).

2.1 Core Components

2.2 Why SFU, Not Mesh or MCU?

For 1,000 participants, mesh is mathematically impossible (each client would need roughly 999 upload streams) and MCU does not scale cost-effectively at that CPU load. The SFU model — extended with cascading across multiple SFU nodes and a “forward only what is needed” policy — is the only architecture that scales economically.

2.3 Component Deep Dive: The Signaling Gateway

The signaling gateway is easy to underestimate because it does not carry media, but it is the nervous system of the meeting. Every join, mute, layout change, active-speaker switch, and permission change flows through it as a small JSON or protobuf message over a persistent WebSocket. It needs to be:

• Horizontally scalable and stateless-ish: Each gateway instance handles a slice of connections; the “who is in which meeting” mapping lives in a shared store (Redis) so any instance can route a message to the right meeting’s participants regardless of which gateway node they are attached to.
• Fast fan-out for control events: When a new participant joins a 1,000-person meeting, that event does not need to be pushed to all 999 others individually and immediately — many UIs only show “999 participants” as a count and lazily fetch the full roster, which meaningfully reduces signaling fan-out at scale.
• Resilient to reconnects: Mobile networks flap constantly; the gateway must support fast reconnection with session resumption so a two-second Wi-Fi-to-LTE handoff does not look like a full meeting re-join to the rest of the system.

2.4 Component Deep Dive: The SFU Scheduler / Placement Service

This service answers one question extremely well: “given a new participant joining meeting X, which SFU node should they connect to?” Its inputs typically include the participant’s approximate geographic location (from IP or client-reported region), the current load and headroom of candidate SFU nodes, and — critically — where other participants of the same meeting are already connected, since keeping a meeting’s participants concentrated on as few nodes and regions as possible minimizes the number of cascade links needed. For a 1,000-participant meeting spanning multiple continents, the scheduler will typically pick one “primary” SFU per region with meaningful participant concentration, and cascade between those regional primaries rather than scattering participants across many small nodes.

Let’s go one layer deeper into how two participants actually establish a media connection, and how the SFU decides what to forward.

3.1 WebRTC Fundamentals

3.2 Simulcast and SVC — the Real Trick Behind Scaling

This is the single most important technique for supporting 1,000 participants with “acceptable” quality.

• Simulcast: Each publisher’s camera encodes and sends multiple independent quality layers simultaneously — for example, a low (180p), medium (360p), and high (720p) stream. The SFU then chooses, per subscriber, which layer to forward based on that subscriber’s available bandwidth and how prominently that video tile is displayed in their UI.
• SVC (Scalable Video Coding): A more efficient evolution where a single encoded bitstream contains embedded spatial and temporal layers, so the SFU can simply drop upper layers rather than juggling entirely separate streams. Codecs like VP9 and AV1 support SVC natively.

3.3 Active Speaker Detection & Selective Forwarding at Scale

At 1,000 participants, no client can render or receive 999 video streams — the math simply does not work on bandwidth, CPU, or screen real estate. So the SFU applies a forwarding policy:

1. Only the current and recent active speakers (typically top 3 to 6 by audio energy) get their video forwarded to everyone as “prominent” tiles.
2. A visible grid of participants (say, the 25 to 49 tiles a client’s UI can display) receive low-resolution and low-framerate simulcast layers.
3. Everyone else’s video is simply not forwarded at all — the client shows an avatar or last frame — audio (if unmuted) is still mixed and forwarded, since audio bandwidth is cheap and human ears are less forgiving of audio gaps than eyes are of video gaps.

3.4 Congestion Control in Depth

Bandwidth on the public internet is never fixed — it fluctuates as other traffic shares the same link, as Wi-Fi conditions change, as a user’s phone switches from 5G to 4G. Real-time media needs to detect these swings within a few hundred milliseconds and react, long before a human would consciously notice buffering. The dominant mechanism is Google Congestion Control (GCC) combined with the Transport-Wide Congestion Control (Transport-CC) RTP header extension:

• Every RTP packet gets a transport-wide sequence number.
• The receiver periodically reports back exactly when each packet arrived, via RTCP feedback packets.
• The sender compares expected vs. actual arrival timing to estimate available bandwidth and building queue delay — a classic delay-based congestion signal, similar in spirit to TCP Vegas rather than TCP Reno’s loss-based approach.
• When the estimate drops, the sender reduces its target bitrate, which cascades into the encoder reducing resolution, framerate, or quantization, and — critically for our design — the SFU dropping to a lower simulcast layer for that specific subscriber.

This feedback loop runs independently per publisher-to-SFU link and per SFU-to-subscriber link, which is exactly why one participant on a poor connection does not degrade quality for everyone else in the meeting — each link adapts on its own.

3.5 Jitter Buffers and Packet Loss Concealment

Network packets rarely arrive at a perfectly steady cadence — this variance is jitter. Each receiving client maintains an adaptive jitter buffer that holds incoming packets for a small, dynamically-tuned window (typically tens of milliseconds) before playback, smoothing out timing variance at the cost of a small amount of added latency. When packets are lost outright, receivers apply Forward Error Correction (FEC) where available, or Packet Loss Concealment (PLC) — an audio codec technique that synthesizes a plausible continuation of the waveform rather than producing an audible gap. For video, a lost packet that breaks a frame typically triggers a keyframe request (PLI — Picture Loss Indication) back to the sender, which is one reason keyframe request rate is a useful health metric at scale.

Let’s trace how a client actually joins a meeting, how steady-state media then flows, and what happens when someone drops.

4.1 Meeting Join Lifecycle

4.2 Steady-State Media Flow

Once connected, each client maintains exactly one media connection to its assigned SFU (not to every other participant). The SFU:

1. Receives each publisher’s simulcast layers.
2. Runs bandwidth estimation per subscriber (via RTCP / Transport-CC feedback).
3. Applies the forwarding policy (active speaker + visible grid + pinned tiles).
4. Rewrites RTP headers (SSRC remapping, sequence-number and timestamp translation) as needed and forwards packets.
5. Emits periodic keyframe requests (PLI/FIR) when a subscriber switches which layer or stream it is receiving, so the new stream can be decoded starting from a full frame.

4.3 Leave / Failure Lifecycle

On graceful leave, the client sends a signaling “leave” message; the SFU tears down that participant’s tracks and notifies others. On ungraceful disconnect (crash, network loss), the SFU detects the absence of RTCP receiver reports or DTLS keepalives within a timeout window (commonly a few seconds) and cleans up state — this timeout is a deliberate trade-off between fast failure detection and false positives from transient network blips.

This is the heart of the interview question, so let’s build it up step by step.

5.1 Why a Single SFU Node Is Not Enough

A single, well-provisioned SFU node can typically handle a few hundred to a couple thousand simultaneous media subscriptions depending on hardware, but a 1,000-participant meeting with even moderate video usage generates enormous fan-out: if only 50 people have cameras on and everyone else watches, that is already up to 50 × 1,000 = 50,000 potential subscription paths if done naively. Add network interface throughput limits, packet-per-second CPU costs, and you hit a wall well before 1,000 raw participants.

5.2 Cascading SFUs

The standard solution is to cascade multiple SFU nodes together into a mesh or tree, so no single node bears the full fan-out load. Each SFU handles a subset of participants directly; SFUs relay a bounded set of “important” streams (active speakers, moderator, pinned users) to each other over dedicated cascade links, so any participant on any node can still see and hear the relevant streams.

5.3 Tiered Roles: Publisher-Heavy vs. Viewer-Heavy Design

In practice, most 1,000-person meetings are “town hall” shaped: a handful of hosts and panelists actively publish video, and hundreds of attendees mostly watch and occasionally unmute. Recognizing this asymmetry lets us apply a hybrid architecture:

5.4 Bandwidth Budget at 1,000 Participants

5.5 Audio Mixing at Scale

Audio has its own scaling curve: even in a 1,000-person meeting, only a handful of people are realistically unmuted and speaking at once. Two strategies exist:

5.6 Screen Sharing at Scale

Screen share deserves special treatment because it behaves differently from camera video: it is usually low motion (text, slides) but needs high spatial resolution and sharpness to remain readable, and it is typically the single most-watched stream in a large meeting. Practically, this means:

• Screen share is often encoded at a higher resolution but lower framerate than camera video, since legibility matters more than smoothness for static content.
• Because screen share tends to be watched by nearly the entire audience simultaneously, it is an ideal candidate to route through the CDN and broadcast tier at very large scale rather than fanning it out via the interactive SFU path to all 1,000 subscribers individually.
• Content-aware encoding (detecting whether the shared content is mostly static slides vs. a video playback) lets the encoder allocate bits more intelligently — spending more on sharpness when there is little motion.

5.7 Breakout Rooms and Sub-Meetings

A 1,000-person meeting sometimes needs to split into many smaller breakout rooms and later reassemble. Architecturally, a breakout room is best modeled as an entirely separate meeting session with its own SFU assignment(s), linked back to the parent meeting by metadata rather than by media-plane coupling — this keeps the breakout traffic isolated (a breakout room’s video should not compete for the same cascade links as the main session) and makes “return everyone to the main room” a simple control-plane operation rather than a media re-negotiation nightmare.

5.8 Admission Control

Every SFU node needs a hard ceiling on how many publishers and forwarded streams it will accept, enforced by the scheduler before assignment — not discovered reactively when the node is already overloaded. When a node approaches its ceiling, the scheduler routes new joiners to a different node (potentially in a different region, accepting a small latency cost) or, for the broadcast tier, hands them off to the CDN fan-out path instead. This is the same admission-control philosophy used in any high-throughput real-time system: it is far better to gracefully redirect the 1,001st participant’s connection than to let node overload degrade quality for the existing 1,000.

Every scaling decision here is really a decision about where complexity lives. Making those trades explicit is what turns “we picked SFU” into a defensible engineering decision.

6.1 Trade-off: Client Complexity vs. Server Simplicity

It is worth pausing on a theme that runs through the entire design: nearly every scaling decision here is really a decision about where complexity lives. A mesh topology puts all the complexity on the client (many outbound streams, many decoders) and almost none on the server. An MCU flips that — the server does all the hard work (decoding, mixing, re-encoding) and the client just plays back one simple stream. The SFU model is deliberately in between, and that middle ground is precisely why it won as an industry default: it keeps servers cheap to scale horizontally (the expensive, hard-to-parallelize work of decoding and encoding never happens server-side for the base case) while keeping client complexity manageable, because modern devices have dedicated hardware video encoders and decoders that make handling a handful of simultaneous streams genuinely cheap in practice.

6.2 Trade-off: Consistency of Experience vs. Cost

A design that gives all 1,000 participants an identical, uniformly excellent experience (every stream high resolution, every audio stream individually mixed, no tiering) is technically possible for a much smaller meeting size, but becomes cost-prohibitive and often physically impossible (bandwidth-wise) well before reaching 1,000 people. The tiered approach in this document deliberately accepts an unequal experience — panelists and active speakers get the best treatment, the long tail gets a leaner one — because that inequality mirrors how large meetings actually function socially. Recognizing when it is acceptable to design for an intentionally uneven experience, rather than treating “fairness” as an absolute requirement, is itself a system design skill worth calling out explicitly in an interview.

Real-time media has a latency budget you can literally count in milliseconds. Let’s make it concrete.

7.1 Latency Budget

Real-time conversation feels natural under roughly 150ms one-way, tolerable up to about 300 to 400ms, and noticeably laggy beyond that. The budget typically breaks down as: capture + encode (10 to 30ms), network transit to SFU (varies by geography, 20 to 100ms), SFU forwarding (1 to 5ms — this is why SFUs, not MCUs, are used for the interactive tier), network transit to receiver, jitter buffer (20 to 60ms, adaptive), decode + render (10 to 30ms).

7.2 Scaling Levers

7.3 Codec Choices and Their Impact on Scale

Codec choice interacts directly with our scaling story: SVC-capable codecs (VP9, AV1) let the SFU drop layers by simply truncating the bitstream rather than juggling entirely separate simulcast encodes, which reduces publisher-side encoding overhead — a meaningful win when panelists in a 1,000-person meeting are often presenting from modest laptops, not dedicated broadcast hardware.

7.4 Capacity Planning Worked Example

Suppose a single well-provisioned SFU node can sustain roughly 4,000 concurrently forwarded video subscriptions before CPU or network headroom runs out (a reasonable order-of-magnitude figure for modern hardware, though real numbers depend heavily on codec, resolution mix, and hardware). In our 1,000-participant town-hall scenario with 10 active video publishers and an average of 50 visible viewer-subscriptions per publisher (grid pagination caps what each viewer actually renders), that is roughly 500 forwarded subscriptions — comfortably within a single node’s capacity, meaning a single SFU (with a standby for failover) could realistically serve the meeting. If instead the meeting design allowed all 1,000 participants to have cameras on and be visible simultaneously to everyone (the naive, rejected design), the forwarded-subscription count would balloon into the hundreds of thousands — this single comparison is usually the clearest way to demonstrate to an interviewer why selective forwarding is not an optional optimization but the core of the design.

A dropped call during a live meeting is one of the worst possible user-facing failures — unlike most systems, you cannot “retry from the last committed state.” The reliability strategy therefore layers several techniques.

8.1 Handling the “Thundering Herd” Reconnect

A subtle but important reliability scenario at 1,000-participant scale: if an entire SFU node (or an entire region) fails, hundreds of clients attempt to reconnect within the same few-second window, all hitting the scheduler and the newly-selected SFU nodes simultaneously — a classic thundering herd. Mitigations include jittered and randomized reconnect backoff on the client side, and the scheduler treating a mass-reconnect event as a distinct load pattern (pre-warming additional capacity or spreading the herd across more nodes than it normally would) rather than routing all of them to the single nearest healthy node and immediately overloading it too.

Video conferencing traffic is intrinsically sensitive — live faces, live voices, sometimes confidential discussions. Security has to be built into the protocol, not bolted on later.

9.1 Threat Model Specific to Large Meetings

A 1,000-participant meeting has a materially larger attack surface than a 4-person call, and it is worth naming the specific threats a design like this needs to account for:

• Link leakage / unauthorized joins (“zoombombing”-style incidents): Mitigated by waiting rooms, per-meeting passcodes, and requiring authenticated identity for anything beyond a small public-webinar tier.
• Denial of service via mass fake joins: The admission-control and rate-limiting logic at the signaling gateway and scheduler layer needs to treat a burst of join attempts for one meeting ID as a potential attack, not just organic popularity, and apply per-meeting and per-IP rate limits accordingly.
• Malicious participant flooding media: A compromised or misbehaving client sending abnormally high bitrate or malformed RTP packets should not be able to degrade the experience for the other 999 participants — the SFU enforces per-publisher bitrate caps and validates packet structure before forwarding.
• Credential / token replay: Meeting join tokens are scoped short-lived and single-meeting, so a leaked token from a past meeting cannot be replayed to join a different or future session.

The metric that actually matters here — perceived call quality — often shows up in client-reported stats before it shows up in server-side resource graphs. That reshapes how you instrument the system.

10.1 Key Metric Categories

Real-time media systems need client-side telemetry as much as server-side, since the client sits at the edge of the actual user experience — WebRTC’s getStats() API is the standard source for this data, periodically reported back to a metrics pipeline (commonly via Kafka into a time-series store) for aggregation and alerting.

10.2 Alerting Philosophy for Real-Time Media

Traditional alerting (CPU above 80% for 5 minutes) is necessary but not sufficient for this system, because the metric that actually matters to users — perceived call quality — is a leading indicator that shows up in client-reported stats before it shows up in server-side resource graphs. A mature monitoring setup for a system like this pairs infrastructure-level alerts with quality-of-experience alerts derived directly from aggregated client telemetry: a sudden spike in freeze rate or reconnect rate across a specific SFU node or region is often the earliest, most reliable signal that something has gone wrong, even before any server-side resource metric crosses a threshold.

SFU nodes are stateful, latency-critical UDP servers — the standard “stateless container, autoscale on CPU” playbook does not apply cleanly.

11.1 Regional Capacity Reservation for Scheduled Mega-Meetings

Unlike a typical web service where load arrives somewhat unpredictably, large 1,000-participant meetings are usually scheduled in advance (a company all-hands, a conference keynote). This is a genuine architectural advantage: the platform can pre-reserve SFU capacity in the target region ahead of the meeting’s start time, rather than relying purely on reactive autoscaling that might not provision fast enough for a sudden thousand-person spike at exactly 9:00 AM. Some platforms expose this as an explicit “large meeting” scheduling flag so the infrastructure can plan capacity proactively rather than treating it as ordinary traffic.

Different pieces of state in this system have wildly different durability and consistency requirements. That is a feature, not a bug — matching each piece to the right store keeps costs low and behavior predictable.

12.1 Why Meeting Metadata and Session State Are Deliberately Split

It is tempting to put everything about a meeting in one database, but this system deliberately splits durable metadata (relational store) from ephemeral live state (in-memory cache) because they have opposite consistency and durability requirements. A meeting’s scheduled time and host list must survive a database failover intact; a participant’s current SFU assignment does not need to survive a Redis restart, because on reconnect the client simply re-requests a fresh assignment. Conflating the two would either force unnecessary durability guarantees onto highly volatile, high-write-rate session data (expensive and slow) or, worse, risk losing durable data by treating it as disposable.

The system decomposes naturally into microservices with very different scaling and latency profiles, which is exactly why they should not live in one monolith.

13.1 A Note on the Odd Service Out

Nearly every service in this list follows the standard modern-microservices playbook: containerize, autoscale on CPU, load-balance behind a generic proxy, deploy with rolling updates. The SFU media plane is the one deliberate exception, and it is worth flagging that explicitly on a whiteboard. It holds long-lived UDP sessions, is sensitive to networking-layer overhead, and cannot tolerate a normal rolling restart mid-meeting. Recognizing that the media plane needs different operational patterns than everything around it is a signal of experience with real-time systems, not just general microservices experience.

The whole system is essentially a careful stack of well-understood patterns — and a matching set of anti-patterns it deliberately refuses to use.

14.1 Patterns to Use

14.2 Anti-patterns to Avoid

A short catalogue of the operational disciplines that separate a system that runs a 1,000-person meeting once from one that runs thousands of them every day.

The same core idea — SFU-style selective forwarding, cascaded across regions, tiered by role — shows up across every major platform. What differs is the branding, the codec mix, and how tightly the media path is coupled to a proprietary backbone.

16.1 Comparative Snapshot

16.2 What Everyone Is Converging On

Across every platform in the table above, the same handful of ideas keep resurfacing: selective forwarding is universal, simulcast or SVC is expected, the biggest tiers are always broadcast-style rather than fully interactive, and inter-region cascade traffic is treated as a first-class concern (either through a private backbone or through careful topology management on the public internet). Where platforms differ is largely in commercial packaging — how they expose the interactive vs. broadcast split to end users — not in the underlying architecture.

The questions candidates hear most often on this topic — and the answers that show a clear understanding of where the true scaling constraints actually live.

A compact recap of the entire design, and the mental model worth carrying into any future system where a shared, latency-sensitive resource must be delivered to many concurrent consumers at once.

If there is one mental model worth remembering long after the specific details of this tutorial fade, it is this: whenever the naive design would require O(N²) delivery across many concurrent consumers, ask what fraction of that delivery is actually consumed — and design the system to forward only that fraction. The savings compound at every layer, and it is precisely why video conferencing at 1,000 participants is a solvable problem instead of a mathematical impossibility.

Correctness under real-time constraints is ultimately not about heroic infrastructure but about identifying, well in advance, exactly which parts of the naive design refuse to scale and refusing to build them that way in the first place. Once you see this pattern clearly here — selective forwarding, tiered roles, per-link adaptation, graceful degradation — you will start recognizing it in every other system where many consumers depend on a small number of shared, live producers: live sports streaming, financial market data fan-out, multiplayer game state synchronization, and beyond.