300 Million Daily Meeting Participants
Sustained peak request volume during high-traffic events.
StreamingStaff Level
Zoom & Google Meet Video Conferencing
Low-latency multi-party video conferencing utilizing WebRTC, Selective Forwarding Units (SFUs), and bandwidth adaptation.
Target Scale
Engineering Scale & Performance SLAs
Target production parameters expected in a senior or staff interview round.
50 Million Concurrent Callers
Daily active users generating read and write operations.
10 PB/day recorded meetings
Projected data ingestion and replication storage capacity.
Glass-to-glass latency < 150ms
Strict end-to-end percentile latency SLA constraint.
Stage 01
Functional & Non-Functional Requirements
Establish clear problem boundaries before proposing architectural components.
Core System Capabilities
- 1-on-1 and group video/audio calls up to 1,000 interactive participants.
- Dynamic screen sharing with high framerate and resolution prioritization.
- Real-time video quality adaptation based on participant network conditions.
- Cloud meeting recording, audio transcription, and breakout rooms.
Reliability & Latency SLAs
- Ultra-low end-to-end latency (<150ms roundtrip) for natural conversational flow.
- Resilient packet loss concealment (tolerating up to 20% UDP packet loss).
- Multi-region media router clustering with sub-second failover.
Stage 02
Capacity Estimation Math
Step-by-step arithmetic conversions for QPS, storage, and bandwidth.
| Dimension | Calculation Formula | Estimated Result |
|---|---|---|
| Simultaneous Active Meetings | 50M concurrent participants / 5 average participants per room | 10,000,000 concurrent meeting rooms |
| Ingress Video Bandwidth per Participant | 720p 30fps H.264 stream = 1.5 Mbps outbound per speaking user | 187.5 KB/s upload bandwidth per user |
| SFU Network Throughput (Global Aggregate) | 50M users * 1.0 Mbps average received video stream | 50 Terabits/second global edge bandwidth |
Stage 03
Multi-Tier Architecture & Component Topology
How requests navigate ingress gateways, application logic, caching, and persistence.
Signaling Gateway (WebSocket) · Session Description Protocol (SDP) Exchange · Redis Room State
Establish ICE/STUN/TURN network handshakes, exchange SDP media parameters, and manage room access tokens.
Geographically Distributed SFU Fleet (Rust/C++) · BGP Anycast Edge · Simulcast Router
Receive upstream UDP video/audio streams and selectively route appropriate bitrate layers to downstream clients without transcoding.
STUN Servers · TURN Relay Servers (UDP/TCP/TLS fallback)
Discover public IP/port mappings and relay traffic through TURN when symmetric corporate firewalls block direct UDP.
Headless Recording Agent · FFmpeg Compositor · S3 Blob Storage · Whisper ASR Worker
Join room as a virtual participant, capture all video/audio streams, composite into an MP4 file, and generate transcripts.
Stage 04
Database Schemas & Partitioning Strategy
Entity models, indexing, and primary key partitioning.
PK: meeting_id
- meeting_id (VARCHAR(64) PK)
- host_user_id (UUID)
- passcode_hash (VARCHAR(128))
- is_active (BOOLEAN)
- sfu_node_id (VARCHAR(64))
- created_at (TIMESTAMP)
Lookup index on host_user_id; fast route to assigned media router node.
PK: participant_id
- participant_id (UUID PK)
- meeting_id (VARCHAR(64))
- user_id (UUID)
- peer_connection_state (VARCHAR(32))
- joined_at (TIMESTAMP)
Composite index on (meeting_id, joined_at) for participant list rendering.
PK: recording_id
- recording_id (UUID PK)
- meeting_id (VARCHAR(64))
- duration_seconds (INT)
- storage_url (VARCHAR(512))
- transcript_url (VARCHAR(512))
Foreign key reference on meeting_id for customer recording archives.
Stage 05
Critical Architectural Trade-Offs
How to defend engineering compromises when challenged by interviewers.
Media Architecture: Mesh vs MCU vs Selective Forwarding Unit (SFU)
Option A: Multipoint Control Unit (MCU: decodes and re-encodes all streams into one)
Option B: Selective Forwarding Unit (SFU: forwards streams without re-encoding)
Rationale: MCUs require massive CPU to decode and transcode video for thousands of calls. SFUs simply inspect packet headers and route raw RTP packets, allowing high density and sub-10ms server processing latency.
Bandwidth Adaptation: Simulcast vs Scalable Video Coding (SVC)
Option A: Simulcast (Client publishes 3 distinct streams: 1080p, 720p, 360p)
Option B: Single Stream with Server Transcoding
Rationale: Simulcast allows the SFU to forward 1080p to the speaker's main viewport while sending 360p thumbnails to gallery participants, optimizing bandwidth without server transcoding costs.
Technical FAQ
Frequently Asked Questions: Zoom & Google Meet Video Conferencing
Key interview questions and conceptual defenses.
Why does Zoom use UDP instead of TCP for audio and video media packets?
TCP retransmits lost packets with head-of-line blocking, causing unacceptable audio stutter. UDP allows dropping minor packets gracefully while keeping conversation real-time.
What happens when a participant's Wi-Fi connection degrades mid-call?
The client detects packet loss via RTCP receiver reports and instructs the SFU to drop to a lower simulcast resolution layer (e.g. 720p down to 360p) or audio-only mode.
Simulate this architecture
Download ClawPad