How do you design a video conferencing system in a system design interview?

Split it into a signaling plane and a media plane. Signaling is a WebSocket service that handles joining, room state and the SDP offer and answer. Media flows as encrypted SRTP over UDP to an SFU near each user, with ICE, STUN and a TURN relay to get through NATs and firewalls. The SFU forwards each viewer a simulcast or SVC layer that fits their network, chosen by congestion control. For a global product, cascade SFUs across regions so each track crosses once, and build recording and webinars as extra subscribers.

Why does video conferencing use UDP instead of TCP?

Live audio and video are useless if they arrive late. TCP stops and resends every lost packet, so one loss delays everything behind it. UDP keeps going, and the media engine hides small gaps. TCP or TLS on port 443 is kept only as a fallback for networks that block UDP.

What do STUN and TURN servers do?

A STUN server tells a device the public IP address and port its NAT shows to the world, so it can offer that address to the other side. A TURN server relays the media when no direct path works, for example behind a strict firewall. STUN is cheap; TURN carries all the relayed traffic, so it is used only as a fallback.

What is cascading in video conferencing?

Joining SFUs in different regions into one room. Each person connects to a nearby SFU, and the SFUs forward each track to each other once. It cuts long-distance traffic and delay; Jitsi measured the next-hop round trip across continents falling from 223 ms to 158 ms after cascading by region.

How does recording work without slowing the call?

The recorder joins the room as a hidden participant that only subscribes. It mixes or saves the tracks and writes MP4 or HLS files to object storage. Because it is just another subscriber, a slow recorder only delays the recording, never the live call.

What is an SFU in video conferencing?

A Selective Forwarding Unit is the media server in the middle of most group calls. Each participant uploads their audio and video once, and the SFU forwards copies to the others without decoding them, choosing for each viewer the quality layer that fits. LiveKit, Jitsi Videobridge and mediasoup are SFUs.

SFU vs MCU: which is better for video conferencing?

For most products, an SFU. It only forwards packets, so it scales and lets each viewer pick their own layout and quality. An MCU decodes every stream, mixes one picture and re-encodes it for each viewer, which is easy on weak clients but heavy on the server and adds delay. MCUs still suit legacy phone dial-in and single mixed outputs.

How many people can a mesh video call support?

Only a few. Each person uploads one copy for every other person, so at 1.5 Mbps of video plus audio, a 10-person mesh needs about 13.9 Mbps of upload from every laptop. In practice a mesh suits 2 or 3 people; beyond that, use an SFU.

What is simulcast in WebRTC?

The sender encodes the same camera several times at different sizes, for example 720p, 360p and 180p, and sends all of them, each named by a rid in the SDP. The SFU forwards each viewer the one layer that fits their screen and network, and switches layers when conditions change, without re-encoding anything.

System design interview guide

Design a Video Conferencing System: WebRTC, SFU vs MCU, Simulcast and Cascading

Short answer

A video conferencing system has two planes. The signaling plane is a WebSocket service that handles joining a room, room state, and the SDP offer and answer that sets up each connection. The media plane carries encrypted audio and video (SRTP) over UDP to a Selective Forwarding Unit (SFU) near each user, after ICE finds a path through NATs with a STUN server, or relays it through a TURN server when no direct path works. The SFU receives each track once and forwards each viewer a simulcast or SVC layer that fits their screen and network, as decided by congestion control. For a global product, SFUs in different regions are cascaded so each track crosses between regions once, and recording and large webinars are built as extra subscribers to the same SFUs.

in this guide

Design a video conferencing system, part by part

8 parts open to everyone · 3 with a free account · 3 with the course

You can read 8 of 14 parts. A free account opens the deep dive; the course opens all of it.

Requirementsopen
Scale estimatesopen

Why this question is asked

It moves you off the usual track of databases and request-response. The hard limits are the network and human perception, not storage. A weak answer draws clients, a server and a database, says 'use WebRTC' and stops. A strong answer separates signaling from media and explains why they need different transports. It knows why two people behind home routers cannot just connect, and what STUN and TURN each do about it. It chooses an SFU over a mesh or an MCU with bandwidth arithmetic, not by name. It explains how one sender can serve a phone on a weak network and a big screen on fast Wi-Fi at the same time. And it handles the global case: what happens when the people in one room are on different continents, and how recording and a 10,000-person webinar fit without slowing the live call.

This page is the free part.

The course goes deeper on the video conferencing system design

₹1,777 in India$49 everywhere elseonce, for the whole course

The System Design course covers the video conferencing system design across a run of lessons, not one page. These 4 alone are about 84 minutes of step-by-step reading, every one with a quiz.

Live from the course bench

Before you design Video Conferencing System, try the questions it rests on.

Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.

Two engineers sketching a system design on a whiteboard

where the work happens

Stuck on a card?

Ask the course tutor. It answers with a real diagram, drawn for your question.

Ask the tutor

Laying out the cards…

Requirements

Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.

Functional requirements

Create a room and join it with a link; see who else is in the room, live
Send and receive audio and video between every participant, plus screen sharing
Mute, turn the camera off, and switch between a speaker view and a gallery of tiles

Go deeper

This guide is built on these 6 lessons. Each one teaches one piece of the video conferencing system design above, step by step.

Practice with 770 system design lessons

Lifetime access for ₹1,777 in India or $49 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.

Get lifetime access See all interview problems

Asked to design Zoom specifically? See the Zoom system design guide

Two courses by the author of this page:

System Design

770 lessons · 18 free to read

₹1,777 in India · $49 elsewhere, once

Get System Design

You own this course

AI Engineering

210 lessons · 10 free to read

₹2,777 in India · $49 elsewhere, once

Get AI Engineering

You own this course

Every lesson in both courses has an AI tutor beside it. It reads the same lesson you are reading and answers your questions from it. Try the tutor

Save your progress and get the interview checklist PDF

System Design Interview Cheat Sheet: the 7 interview stages, the 10 points a scorecard grades, 12 classic systems. 18 pages. Free with an account.

A video call looks simple: you see people and hear them. Underneath, every laptop and phone must find a network path to the others, often through home routers and office firewalls that block most traffic. Then each camera's video must reach every other person in the call, live, with less delay than a person notices, while each person's network gets better and worse from second to second. Take an interview-sized target: 1 million people in calls at the same moment, 5 to a room. With three video layers per camera, that is about 2.2 terabits a second flowing into the media servers and about 2.1 flowing out. No single machine can do this, and no single region either: a room with people in Mumbai and Frankfurt should not send every stream across the world twice. This guide builds the design on the open standards that every browser ships and that open-source media servers such as LiveKit, Jitsi and mediasoup are built on: WebRTC.

A video conferencing system lets a group of people send live audio and video to each other with very little delay. First, some terms. WebRTC (Web Real-Time Communication) is the open standard built into every modern browser and phone for live audio, video and data. A track is one stream of media, such as one camera or one microphone. Latency is delay; jitter is how much that delay changes from packet to packet. A NAT (network address translation) is the box, usually your home or office router, that lets many devices share one public IP address; it also blocks most traffic that you did not start yourself. The design has two planes. The signaling plane is a small, reliable channel, usually a WebSocket (a connection that stays open so the server can send messages at any time). It handles joining a room, sign-in, and swapping SDP (Session Description Protocol), the text that says which codecs and tracks each side will use. The media plane carries the actual audio and video as SRTP (Secure Real-time Transport Protocol, encrypted media packets), usually over UDP, because a late packet of live audio is useless and UDP does not stop to resend it. To get through NATs, each client uses ICE (Interactive Connectivity Establishment): it collects possible addresses with the help of a STUN server, tests them, and falls back to a TURN server that relays its media when no direct path works. In the middle sits a media server, almost always an SFU (Selective Forwarding Unit): every client uploads its tracks once, and the SFU forwards each viewer the copies it needs without decoding them. Simulcast and SVC let the SFU give each viewer a quality that fits their screen and network, and congestion control decides that quality from moment to moment. For a global product, SFUs in several regions are joined into one room (cascading), and recording and large webinars are built as extra subscribers to the same SFUs.

Roni Das

23 October 2026 · 38 min read

Where it shows up

Asked as 'design a video conferencing system', 'design Google Meet', 'design a video calling app' or 'design Zoom', and inside questions about live streaming, voice chat for games, telehealth, online classrooms and customer support video. Companies that build real-time products ask it in depth: video, collaboration, social apps, cloud communication platforms, and any team running WebRTC infrastructure.

Spec sheeta video conferencing system

01Upload per person with simulcast: about 2.2 Mbps
02A 10-person call with a mesh: 13.9 Mbps up per laptop, 90 streams
03The same call with an SFU: 2.2 Mbps up, 4.9 Mbps down, 48.6 Mbps out of the server
04Fleet traffic at peak: about 2.19 Tbps in, 2.11 Tbps out, about 440 machines by bandwidth

worked through below, with the maths

Data modelfree account

Deep dives (9)free account

Unlock with the course · $49One payment, lifetime access to every lesson.

The hard parts of this design are taught step by step in the System Design course: WebRTC, UDP and NAT.

WebRTC
Real-time peer-to-peer communication in the browser, the technology behind video calls, screen sharing, and live streaming.
24 min · diagrams · quiz
UDP
The 'fire and forget' transport protocol that prioritizes speed over reliability.
17 min · diagrams · quiz
NAT
Network Address Translation, how millions of devices share a single public IP address.
21 min · diagrams · quiz
WebSockets
Full-duplex, persistent connections, how the real-time web actually works.
22 min · diagrams · quiz

all part of

System Design Masterclass

770 lessons · about 283 hours · 18 free to read

₹1,777in India, by UPI

$49everywhere else, by PayPal

Get the System Design course Read 18 lessons free first

You own this course

Continue with WebRTC

pay once,
yours for life

Work from browsers and mobile apps, including networks that block UDP

Reconnect after a short network drop without leaving the call

Record a call to a file, and stream a large webinar to many viewers who mostly watch

Non-functional requirements

Low delay: media should arrive as fast as the network distance allows, because extra delay makes people talk over each other
Keep working through packet loss and changing bandwidth by lowering quality, not by freezing
Each viewer gets a quality that fits their own screen and network, without slowing anyone else
Encrypted media on every hop; optional end-to-end encryption where the server must not see media
Scale out: more rooms means more media servers, and one region failing must not end every call
Users connect to a media server near them, even when the people in one room are in different countries

Back-of-envelope scale estimates

Show your math. Pulling numbers from thin air signals you have not thought about the load.

Upload per person with simulcast

about 2.2 Mbps

Interview assumptions: three video layers, 720p at 1,500 kbps, 360p at 500 kbps and 180p at 150 kbps, plus 40 kbps of audio. 1,500 + 500 + 150 + 40 = 2,190 kbps up per person. Simulcast costs the sender more upload so that the server never has to re-encode.

A 10-person call with a mesh

13.9 Mbps up per laptop, 90 streams

In a mesh, everyone sends to everyone. Each laptop encodes and uploads 9 copies of its 720p stream with audio: 9 x 1,540 = 13,860 kbps up, and the same down. The call has 10 x 9 = 90 streams. Most home connections cannot upload that, which is why a mesh only suits very small calls.

The same call with an SFU

2.2 Mbps up, 4.9 Mbps down, 48.6 Mbps out of the server

Each person uploads once, 2,190 kbps. In a gallery of 9 tiles at 360p, each person downloads 9 x 540 = 4,860 kbps. The server receives 10 x 2,190 = 21,900 kbps and sends 10 x 4,860 = 48,600 kbps, but decodes nothing. LiveKit's own example checks out the same way: 50 people each receiving 49 streams at 500 kbps is 50 x 49 x 500 kbps = 1.225 Gbps from one server.

Fleet traffic at peak

about 2.19 Tbps in, 2.11 Tbps out, about 440 machines by bandwidth

Interview assumptions: 1,000,000 people in calls at once, 5 per room, so 200,000 rooms. In speaker view each person receives 1 stream at 720p, 3 at 180p and 4 audio streams: 1,500 + 450 + 160 = 2,110 kbps. In: 1,000,000 x 2,190 kbps = 2.19 Tbps. Out: 1,000,000 x 2,110 kbps = 2.11 Tbps. If one SFU machine safely moves 5 Gbps each way (a 10 Gbps network card kept half full, an assumption), that is 2.19 Tbps / 5 Gbps = 438 machines.

Fleet size by CPU

about 16,000 cores, or 500 machines of 32 cores

A consumer is one track that one person receives. In a 5-person room each person receives 4 video and 4 audio tracks, so 1,000,000 x 8 = 8,000,000 consumers. mediasoup's docs say one worker runs on one CPU core and can typically handle over about 500 consumers. 8,000,000 / 500 = 16,000 cores, which is 500 machines of 32 cores. Bandwidth and CPU give a similar answer here; plan for the larger.

TURN relay traffic

about 430 Gbps

Interview assumption: 10% of people cannot get a direct path and use a TURN relay, so 100,000 people. The relay carries both their upload and their download: 2,190 + 2,110 = 4,300 kbps each, so 100,000 x 4,300 kbps = 430 Gbps. RFC 8656 warns that relaying comes at a high cost to whoever runs the TURN server, so it is the last resort, not the default path.

One room across two regions

40 long-distance streams without cascading, 10 with it

A 10-person room: 6 people in Mumbai, 4 in Frankfurt, gallery view of 360p tiles. With one SFU in Mumbai, each Frankfurt person sends their upload across and pulls 9 tiles back across: 4 + 4 x 9 = 40 streams, 28.2 Mbps on the long path. With an SFU in each region joined together, each track crosses once: 6 + 4 = 10 streams, 5.4 Mbps. That is 5.2 times less long-distance traffic, and every person talks to a nearby server.

Recording storage

about 1.1 GB per recorded hour

Interview assumption: one composed 1080p recording at 2,500 kbps. 2,500 kbps x 3,600 seconds / 8 = 1.125 GB an hour. If 10% of the 200,000 rooms record at peak, that is 20,000 recorders writing about 22,500 GB an hour.

High-level architecture

Draw two planes, and keep them apart. The signaling plane is on top: clients open a WebSocket to a signaling service over HTTPS. Through it they sign in, join a room, learn who else is there, and swap SDP offers and answers and ICE candidates. The standard leaves this channel to you: JSEP, the rulebook for how a browser creates offers and answers, says how those messages travel is 'left entirely up to the application'. Behind the signaling service sits the room state: who is in each room, which tracks each person publishes, who is muted, and which media server hosts the room. Keep it in a fast shared store or a pub/sub bus. LiveKit, for example, uses Redis for room data and as a message bus between nodes. The media plane is below. Each client connects to an SFU near it. Media flows as SRTP, encrypted with keys agreed through DTLS (a version of TLS for UDP), over UDP where possible. To find a path through home routers and firewalls, the client uses ICE with a STUN server, and falls back to a TURN relay, which can run over TLS on port 443 so that it looks like normal web traffic. The SFU receives each person's tracks once, as several simulcast layers, and forwards each viewer the layer that fits their screen and network. Congestion control feedback, sent back over RTCP (the control messages that travel next to the media), tells each sender how much to send. For a global product, put SFUs in several regions. When a room has people in more than one region, the SFUs join the room together and send each track across once (cascading). Recording and webinars are extra subscribers: a recorder joins the room like a hidden participant and writes files to object storage; a webinar fans one speaker's tracks out through a tree of SFUs to many viewers.

In a real interview, sketch this on the whiteboard before diving into any single box.

One person joins a call, from link to live video

Follow a browser in Mumbai joining a room that already has people in Frankfurt. This is a good order to explain it in an interview.

1
Join through signaling
The browser opens a WebSocket to the signaling service and asks to join room 42. The service checks the user may join, looks up the room state, and finds that the room is already live on an SFU in Frankfurt.
2
Pick a nearby SFU
The person is in Mumbai, so the service picks an SFU in the Mumbai region with spare capacity and tells it to join room 42 too. The Mumbai and Frankfurt SFUs link up for this room.
3
Offer and answer
The browser and the Mumbai SFU swap SDP through the signaling channel: which codecs, which tracks, and three simulcast layers for the camera, each named by a rid (restriction identifier).
4
Find a path with ICE
The browser gathers candidates: its own local address (host), the public address a STUN server reports (server reflexive), and a TURN relay address (relayed). It sends them as it finds them (trickle ICE). Both sides run connectivity checks on candidate pairs, and the best pair that works is nominated.
5
Secure the media
A DTLS handshake runs over the chosen path and produces the keys for SRTP. Plain unencrypted media is not allowed in WebRTC.
6
Publish and subscribe
The browser starts sending its three camera layers and its audio. The Mumbai SFU forwards them to local viewers and sends one copy of each needed layer to the Frankfurt SFU, which forwards it to the people there. The browser subscribes to the Frankfurt people's tracks the same way, in reverse.
7
Adapt, all the time
Every few tens of milliseconds, feedback from the receiving side tells each sender about delay and loss. If a viewer's network gets worse, the SFU switches that viewer to a lower layer at the next key frame. Nobody else is affected.

Core components

Walk through each service. The interviewer wants to hear what each one owns, not just the names.

Signaling service

WebSocket servers that handle sign-in, joining and leaving, SDP offers and answers, ICE candidates, mute and layout events, and chat. Small messages that must arrive, so they use a reliable connection. Stateless apart from open connections; room facts live in the room state store.

Room state store and bus

Holds who is in each room, which tracks they publish, which SFU nodes host the room, and per-node load. A fast shared store plus pub/sub, so every signaling server and SFU sees changes within milliseconds. LiveKit uses Redis for this. In Jitsi, a central server runs Prosody for signaling and Jicofo, which assigns each conference to a bridge.

STUN and TURN servers

STUN answers one question: what public IP address and port does my NAT show to the world? TURN relays media for clients that cannot get a direct path. Run TURN in every region, on UDP and also over TLS on port 443 for networks that block everything else, and plan for its bandwidth.

SFU (Selective Forwarding Unit)

The media server. Terminates ICE, DTLS and SRTP for each client, receives each track once, and forwards copies to subscribers, choosing a simulcast layer or SVC layer per viewer. Never decodes the video. Examples: LiveKit, Jitsi Videobridge, mediasoup.

Node selector and region router

Chooses which SFU hosts a person: the nearest region, then a node below a load limit. LiveKit's region-aware selector picks the closest region and a node under its sysload_limit; Jitsi's Jicofo picks a videobridge per conference, by region when cascading is on.

Cascade links between SFUs

Server-to-server media connections that join one room across several SFUs. Jitsi's bridges connect with ICE and DTLS and then exchange standard SRTP. Each receiving server pulls a track once and fans it out locally.

Recorder and webinar fan-out

A recorder joins the room as a hidden subscriber, mixes or saves tracks, and writes MP4 or HLS files to object storage. LiveKit's egress joins as a participant of kind EGRESS and subscribes only to the tracks it needs. For webinars, extra SFUs subscribe to the speakers and fan out to viewers.

the deep dive

Data model

room. Durable record in a normal database. The live parts (who is in, where) are in the room state store, because they change every second and are thrown away when the room…

free with an account

Every table for a video conferencing system, its keys, and which store fits it and why.

One tap with Google. Free, no card.

the deep dive

Deep dives

Signaling: offers, answers and room state. Before any video flows, the two sides must agree on what they will send and how. WebRTC does this with SDP (Session Description Protocol), a text format that lists the…

free with an account

9 deep dives on the parts that break at scale, with 3 diagrams: Signaling: offers, answers and room state; Getting through NATs: ICE, STUN and TURN; SFU vs MCU vs mesh, with the arithmetic.

One tap with Google. Free, no card.

the deep dive

Trade-offs to discuss

SFU vs MCU vs mesh. A mesh needs no server but each client uploads one copy per other person, 13.9 Mbps in a 10-person call, so it suits 2 or 3 people. An MCU sends each client one mixed…

free with an account

6 decisions an interviewer expects you to defend, each with the alternative and why it loses here.

One tap with Google. Free, no card.

for course owners

What the interviewer asks next

A user in a hotel can join the room and see the participant list, but no video ever arrives. What happened?

with the System Design course

5 follow-up questions with model answers, the interview scorecard for this question, and a mock interview on Design a video conferencing system with the AI tutor.

Unlock with the course · $49One payment, lifetime access to every lesson.

How a video conferencing system actually does it

The open-source media servers show the same shape this guide draws. LiveKit runs one room per node in its open-source distributed mode, with Redis for room data and messages, a region-aware node selector, and an egress service that records by joining the room as a hidden participant; its cloud joins servers in several data centres into one session as a mesh. Jitsi Meet splits signaling (Prosody and Jicofo) from media (Jitsi Videobridge), lets Jicofo pick a bridge per conference, and cascades bridges across regions, which cut next-hop round trip time from 223 ms to 158 ms on meet.jit.si. mediasoup is an SFU library where each worker runs on one CPU core, and routers are joined with pipeToRouter for larger rooms and broadcasts. Under all of them are the same IETF and W3C standards: ICE, STUN and TURN for getting through NATs, SDP offer and answer for setup, DTLS-SRTP for mandatory encryption, simulcast and SVC for layers, and GCC-style congestion control.

Sources

the question most readers have next

What would you have to get right to run the video conferencing system design for real users?

The design on this page is the shape. Running it means handling the failures, the load and the data that the shape does not show. The lessons below teach those parts, starting with "WebRTC".

Where this is used in industry

The real examples, each with its source, are on this page: How a video conferencing system actually does it.

The lessons that teach the next part

Real-time peer-to-peer communication in the browser, the technology behind video calls, screen sharing, and live streaming.
WebRTCSystem Design course24 min
The 'fire and forget' transport protocol that prioritizes speed over reliability.
UDPSystem Design course17 min
Network Address Translation, how millions of devices share a single public IP address.
NATSystem Design course21 min
Full-duplex, persistent connections, how the real-time web actually works.
WebSocketsSystem Design course22 min

Stuck on a step? Every lesson has an AI tutor beside it. Ask it your question and it answers from the lesson you are reading. Try the tutor

Get the free System Design Interview cheat sheet (PDF)

Where this is taught

System Design Masterclass

770 lessons · about 283 hours · 18 free to read

₹1,777 in India by UPI$49 elsewhere by PayPal, once, for life

See the System Design course

You own this course

Frequently asked questions

India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.

NEWSystem Design Hands-On

Included in the System Design course: real systems, built live

Postgres Sharding: Complete Hands-On (PgBouncer + Citus). 2 h 36 min and 20 chapters: one PostgreSQL loaded until it breaks, then four shards behind a router you write, PgBouncer and Citus, with the 139-page slide deck. The first 15 minutes are free to watch.

Watch the free 15 minutes See System Design Hands-On

Free PDF · 79 pages

25 real tech interview questions, answered in full

Five from each of our AI, GenAI, Inference, Maths for ML and Forward Deployed packs. Each with a diagram and a model answer. Free by email.

free tool

Check these numbers yourself

Put in your own guesses for a video conferencing system and see requests per second, storage, bandwidth and servers, with every sum written out.

Open the Capacity Estimator

Also by the same author

210 lessons · about 219 hours · 10 free to read

₹2,777 in India by UPI$49 elsewhere by PayPal, once, for life

See the AI Engineering course

what a reader said

It is really nice and good Please join the course

Gyan Kumar, Analyst, Bangalore · System Design Masterclass · read 3 lessons · all reviews

Design a Video Conferencing System: WebRTC, SFU vs MCU, Simulcast and Cascading

Design a video conferencing system, part by part

Why this question is asked

The course goes deeper on the video conferencing system design

Before you design Video Conferencing System, try the questions it rests on.