WebRTC and selective forwarding units
Real-time calls: peer-to-peer for two, a forwarding server for a hundred.
01The intuition
The problem it solves
A video call is not like a video on YouTube. There is no file to prepare in advance; the picture is made now and must reach the other person within about 150 ms or the conversation feels like a walkie-talkie. The ordinary web path, where a browser sends a request to a server and the server answers over TCP, is too slow in two ways: TCP waits to resend a lost packet, which stalls the whole stream, and every byte makes a round trip through a server even when the two people sit in the same office.
Two people can solve this by talking directly. But a class of 30 students on a call cannot: if each sends their video to every other student directly, each phone uploads 29 copies of its own stream.
29 streams × 1.5 Mbps = 43.5 Mbps upload per student, far beyond a home connection
Build it one piece at a time
Step 1: use UDP and accept loss. WebRTC sends audio and video as small UDP packets with timestamps (RTP). A lost packet is not retransmitted if it would arrive too late; the decoder conceals the gap, which the viewer barely notices. Latency stays low because nothing waits.
Step 2: find a path between two devices. Both phones sit behind home routers that hide their addresses. Each asks a small public server (STUN) "what address do you appear as from outside", exchanges the candidates with the other party through your signalling service, and tries them in order (ICE). Most pairs connect directly. For the few that cannot, a relay server (TURN) forwards the packets.
Step 3: two people: peer to peer. Asha and Ravi now send media straight to each other. Your servers carried only the signalling (a few kilobytes) and perhaps a TURN relay. This is the cheapest possible call.
Step 4: a room: a selective forwarding unit (SFU). For the class of 30, every student sends one stream up to a server, and the server forwards copies to the others without decoding them. Upload per student drops from 29 streams to 1; the server does no video processing, only packet copying, so one machine serves hundreds of participants.
| Topology | Upload per participant | Server work | Good for |
|---|---|---|---|
| Mesh (peer to peer) | n − 1 streams | none | 2 to 4 people |
| SFU | 1 stream | copy packets | 5 to a few hundred |
| MCU (mixing server) | 1 stream | decode, compose, re-encode | legacy devices, recordings |
Step 5: send several sizes at once. With simulcast, each participant uploads the same video at three resolutions. The SFU forwards the small one to a phone showing a 5×6 grid and the large one to the laptop showing a single active speaker. Nobody is re-encoded, and each viewer gets what fits.
Why it works, with the numbers
The SFU turns a quadratic problem into a linear one. In a mesh the total traffic for n participants is n(n − 1) streams; with an SFU it is n up and about n(n − 1) down, but the downstream is split across participants and shaped by simulcast. For a 100-person meeting where each viewer watches 9 tiles at 300 kbps:
download per viewer ≈ 9 × 0.3 Mbps = 2.7 Mbps, server egress ≈ 100 × 2.7 Mbps = 270 Mbps
which is one server, not a data centre. The guarantee is a latency target, typically under 150 ms one way; it is kept by placing SFUs in each region and routing a participant to the nearest, with SFUs forwarding between regions for a global meeting. The failure modes: a region's SFU dying drops every call on it, so clients reconnect to another; packet loss above a few percent degrades video first, audio last, by design; and TURN relays cost real bandwidth money, so they are a fallback, not the default.
The trade-off you must say out loud
Peer to peer is free and private but does not scale past a handful; an SFU scales and allows recording and moderation but puts your servers in every packet's path and makes end-to-end encryption harder. An interviewer will ask what happens for a 10,000-viewer webinar, where the answer changes shape: a few presenters through an SFU, everyone else through a one-second-latency streaming pipeline.
Where it shows up in the 100 Google problems
- Design Google Meet: signalling over WebSockets, STUN and TURN for connectivity, regional SFUs with simulcast, and a separate path for recordings and large broadcasts.
- Live chat for a YouTube stream sits next to a live video that uses the streaming pipeline rather than WebRTC, which is why it tolerates seconds of delay.
- Design Google Home streams microphone audio with the same low-latency instincts, though over a single server connection.