Messaging & realtime · Advanced

Zoom-style video calls

WebSocket signalling, an allocator placing meetings on SFUs, UDP media with TURN fallback.

Every part, and why it is there

Meeting clients

Each participant sends their own camera and microphone once and receives everyone else’s. They talk to the system on two separate planes: signalling (control) and media.

Load balancer

HTTPS and WebSocket traffic for joining, chatting and controls. Media never goes through here.

Meeting API

Schedules meetings, checks the passcode and who may join. Ordinary request/response work.

Meetings & users

Meeting ids, hosts, settings and participants. Small and relational.

Signalling service

Coordinates the call: who is in the room, mute state, and the session descriptions (SDP) and network candidates (ICE) the clients need to reach the media server.

Room state

Live participant lists and which media server hosts each meeting. Lives in memory because it changes every second and is gone when the call ends.

Media server allocator

Picks a media server for a new meeting: close to the participants and lightly loaded. Everyone in that meeting is then pointed at the same server.

Media server registry

Every media server reports its health and load here every few seconds. A server that stops reporting is taken out of rotation and its meetings move.

UDP media entry

A layer-4 entry for UDP media packets. Real-time audio and video use UDP because a late packet is useless; retransmitting it (as TCP would) only adds delay.

TURN relay

For users behind strict corporate firewalls that block UDP, a relay carries media over TCP/TLS on port 443. Slower, but it works almost everywhere.

SFU media servers

A selective forwarding unit receives each person’s stream once and forwards copies to the others without decoding. It picks a lower-quality layer for people on poor connections. Mixing into one video (an MCU) would cost far more CPU.

Recording stream

If recording is on, the SFU sends a copy of the streams here so a recorder can compose them without slowing the live call.

Recording composer

Decodes, lays out and encodes the recording into one video file. CPU-heavy and not real-time, so it is kept off the live path.

Recordings

Finished meeting recordings for later playback and download.

Asked in interviews at

  • apple

Learn more

All system design examples