Design Google Meet

Problem statement

Design a real-time video conferencing platform accessible entirely through a web browser with no plugin, extension, or native client required. Users join scheduled meetings via calendar links or ad-hoc meetings via shareable URLs. The platform supports in-browser audio/video calls using WebRTC, optional screen sharing, live captions and transcripts, auto-recording to cloud drive, background blur, and in-meeting chat. Meetings integrate tightly with a productivity suite: calendar events carry join links, domain-restricted meetings enforce organizational boundaries, and single sign-on eliminates friction.

This is not a simple WebSocket chat application. A video conference is a multi-party, latency-critical, bandwidth-hungry, NAT-hostile media pipeline that must feel instantaneous to participants separated by continents, firewalls, symmetric NATs, and corporate proxies. The browser constraint eliminates every native trick: no custom UDP sockets, no raw codec access, no direct peer wiring beyond what WebRTC permits. Every byte of media must traverse a sanctioned path — typically a Selective Forwarding Unit (SFU) — because a full peer-to-peer mesh collapses beyond four or five participants.

Why the problem is distinctive

A text messaging system can tolerate seconds of delay. A video call cannot. The end-to-end glass-to-glass budget is roughly 150 ms one-way before users perceive degradation, and 400 ms before calls become unusable. Every hop — capture, encode, packetize, network traversal, SFU processing, decode, render — consumes a slice of that budget. The platform must simultaneously optimize for latency, bandwidth efficiency, NAT traversal reliability, and horizontal scalability to hundreds of millions of concurrent participants.

The browser constraint compounds the difficulty. WebRTC provides the primitives — getUserMedia, RTCPeerConnection, RTCRtpSender/Receiver, Data Channels — but the application layer must implement signaling, session management, media routing, NAT traversal orchestration, adaptive bitrate control, and failure recovery from scratch. The browser sandbox also limits compute available for background blur and speech-to-text, pushing those workloads server-side or into WebAssembly/ONNX runtimes.

The four architectural planes

1. Signaling and control plane: meeting creation, calendar integration, participant roster, SDP offer/answer exchange, ICE candidate trickling, mute/raise-hand state, and chat. Latency budget: 100–500 ms. Availability target: 99.99%.
2. Media transport plane: the SFU mesh that receives, optionally transcodes, and forwards RTP/SRTP streams. Latency budget: under 20 ms added per hop. This is the hot path.
3. Media intelligence plane: live captions (speech-to-text), recording (composite mix and object storage), background blur (segmentation model), noise suppression. These bolt onto the media path but tolerate 200–2000 ms of additional latency.
4. Identity and policy plane: SSO, OAuth 2.0 / OpenID Connect, domain restrictions, ephemeral meeting links, trust-and-safety moderation. This plane gates access but sits outside the media hot path.

A strong answer keeps these planes separate. The media plane must survive signaling-plane degradation. The intelligence plane must not introduce back-pressure into the transport plane. The identity plane must reject unauthorized participants without disrupting the media of those already connected.

Public operating baseline

Google reported 100 million daily meeting participants on Meet by April 2020, rising to 3 billion meeting minutes per day at peak. Zoom reported 300 million daily meeting participants and 3.3 trillion meeting minutes in calendar year 2020. Discord surpassed 150 million monthly active users with voice-first WebRTC. These are cited public figures that establish the category is real at extreme scale. Every uncited number in this answer is an explicit design assumption.

For capacity planning, this answer assumes a mature platform with 80 million daily active participants, 12 million concurrent participants at global peak, 4 million simultaneous meetings, and a 3× event multiplier for Monday-morning stand-ups and product-launch weeks.