Design video calls like Zoom

A video call service lets a few people, or a few hundred, see and hear each other with a delay under 300 ms, short enough for conversation. Its design keeps three kinds of traffic apart. Signalling is a WebSocket from each participant to a meeting service, which admits people to rooms and carries the session descriptions and network candidates that WebRTCWebRTC: A browser standard for sending audio, video and data directly between peers, once the application has introduced them through a signalling channel of its own. More in “Real-time delivery: polling, SSE and WebSockets” needs to connect. Media is WebRTC audio and video between each participant and a nearby SFU, a server that forwards streams without decoding them. Every camera sends several qualities, called simulcast layers, and each receiver gets the layer its screen and network can use. TURN relays carry media for networks that block direct paths, and meetings that span continents link SFUs in several regions. Recording, chat and captions join the meeting as participants or ride on signalling.

Delay rules calls, and media is the cost

What makes calls different

Calls are interactive, so delay matters more than picture quality: the IETF’s requirements for congestion control describe interactive media as needing delivery within hundreds of milliseconds end to end (RFC 8836). Nothing can be cached, because every frame is new, and every participant costs server bandwidth in both directions. Products such as Zoom and Google Meet run meetings from two people to hundreds, often on office networks that allow little more than HTTPS.

Requirements

People join from a link, send and receive audio, video and screen shares, chat, raise hands and record. Meetings hold up to 300 people, and webinars add thousands who only watch. The service keeps mouth-to-ear delay under 300 ms within a region, shows the first video within a second of joining, works on networks that allow only HTTPS, never lets one person’s weak network lower everyone’s quality, and carries 1 million people in calls at the peak.

Estimates

Work each figure out from these assumptions, then check yourself:

Assumed	Value
People in calls at the peak	1 million, in meetings of 6 on average
Each camera sends	layers of 1,500, 500 and 150 kbit/s, plus 32 kbit/s of audio
Each person receives	the speaker in high quality, four thumbnails, the three loudest voices
One SFU server	7 Gbit/s of its 10 Gbit/s port
Need a relay	15 % of people

That is about 166,667 meetings, 2.2 Tbit/s leaving the SFUs, about 314 servers on bandwidth alone, and 657 Gbit/s through relays. Media is the cost; the signalling of a whole meeting fits in a few kilobytes.

The first design

In the diagram, a participant opens the link and connects a WebSocket to signalling. The meeting service checks the token and assigns the room an SFU near its first participants. The client and the SFU exchange an offer and an answer through signalling; ICE finds a path, through a TURN relay if nothing direct works, and DTLS sets up the keys that encrypt every media packet. From then on media flows to the SFU, which forwards layers to the others. Step through it:

The drawing shows the whole scene; its 6 steps are listed below.

Every step as text

1. Signalling first. The participant opens the link, and the app connects a WebSocket to signalling. Signalling carries only joins, descriptions and candidates, a few kilobytes per meeting.
2. A room and an SFU. The meeting service checks the token and assigns the room an SFU near its first participants.
3. Offer and answer. The client and the SFU exchange an offer and an answer through signalling. Signalling only passes them on.
4. A path, relayed here. ICE tests the paths to the SFU, direct ones first. This participant's network blocks them, so the path that works goes through a TURN relay, drawn dashed.
5. Keys for every packet. A DTLS handshake on that path sets up the keys that encrypt every media packet between the participant and the SFU. The relay passes on packets it cannot read.
6. Media flows. From then on media flows to the SFU, through the relay for this participant, and the SFU forwards to each of the others the simulcast layer their screen and network can use.

The options, by name

A mesh connects every participant to every other one, which suits two or three people. An SFU forwards each sender’s streams to the others without decoding them. An MCU decodes, mixes and encodes one stream per receiver. Simulcast sends several encodings of one camera, while SVC sends one layered stream from which a server drops layers. TURN relays media when no direct path works. Cascading links SFUs in several regions into one meeting. SFrame encrypts media end to end, so the SFU forwards what it cannot read.

The deep-dive questions

1. How does a participant get from the join button to the first video, and how long does it take?
2. How much does an SFU forward for each meeting size, and what limits a server first?
3. How does a receiver on a weak network get a lower layer without lowering everyone else’s?
4. How do people behind strict firewalls connect, and how large is the relay fleet?
5. How does a meeting across three continents stay fast?
6. Where do recording, chat, captions and end-to-end encryption fit?
7. What happens when an SFU, a relay or a region fails, and what breaks at 10× and 100×?

Signalling: a small relay that never reads a description Pro: opens with a Pro, Premium or Ultimate pass

In this part:

• Joining a call, step by step, with the time to first video
• Forwarding media: what an SFU carries, measured by meeting size
• A weak link, reproduced: choosing a layer for each receiver
• Strict firewalls: ICE, TURN and consent, with numbers
• One meeting across three continents: cascading SFUs, measured
• How recording, chat, captions and webinars join a call
• End-to-end encryption with SFrame, and what it costs
• Failure drills: an SFU, a relay and a region
• Bottlenecks at 10× and 100×, and the designs rejected
• What each level covers, and a practice round of 45 minutes
• Practise: choose a layer with margins
  • Choose a simulcast layer for one receiver
• Interview questions
  • An SFU hosting 400 meetings crashes, and every participant's video freezes. Walk through what the apps and the meeting service do in the next ten seconds, and what you design in advance so that most meetings recover within five seconds.
  • In a 12-person meeting, one participant joins from a train and everyone's video turns blurry. Explain why the design allows this, and change it so that only that person's quality drops.
  • A company all-hands has 2,000 people: 900 in Bengaluru, 700 in London and 400 in São Paulo. Ten people speak and everyone else only watches. Design the media path, with delay and bandwidth numbers for your choice.
• Key takeaways

3 diagrams · 6 runnable examples (JavaScript, Python) · 1 exercise with sample tests · 3 interview answers · about 48 minutes

Opening this part with your pass…

This part opens with any MySmartCoPilot pass.

• Pro pass · 1 week · ₹79 · $2.99
• 30 days · ₹179 · $5.99
• 1 year · ₹1,699 · $45

One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

Choose a passI have a licence key

It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

Read a complete sample first: Design a chat app like WhatsApp: delivery