Design Mobile Video Conferencing: Zoom, FaceTime, and WebRTC

Updated July 26, 2026 · techinterview.org

Mobile video conferencing is one of the most demanding mobile system design problems. The interview tests whether you can design a system that handles real-time audio/video over unreliable networks, balances bandwidth across participants, and keeps the call going through cellular handoffs and screen locks.

Functional requirements

• 1:1 and group video calls (up to 50+ participants). The jump from two callers to a group is where the design gets interesting, so be ready to explain why the architecture has to change as participant count grows rather than treating both cases the same.
• Audio and video streams. Treat these as separate streams with separate priorities; interviewers expect you to say audio matters more than video and should be the last thing to degrade under pressure.
• Screen sharing. A screen share is high-resolution but low-motion, so it compresses well with a different encoder profile than a talking-head camera feed. Expect a follow-up on how you send screen and camera at the same time.
• Chat sidebar. This rides a separate reliable channel (a WebRTC data channel or a plain WebSocket) because text has to arrive in order and never drop, unlike media where a lost frame is fine.
• Mute, camera toggle, virtual backgrounds. Mute and camera toggle are cheap state changes, but virtual backgrounds run a segmentation model on every frame on-device, so call out the CPU/GPU cost and that it’s a reason to drop resolution when the phone gets hot.
• Background mode (audio-only). When the app goes to the background or the screen locks, video encoding should stop to save battery while audio keeps flowing so the conversation continues.

Non-functional

• Sub-200ms p99 audio latency. Past roughly 200ms of one-way mouth-to-ear delay, people start talking over each other; this target is what pushes you to place media servers close to users geographically.
• Smooth video at variable bitrates. Consistent frame delivery beats peak resolution — a steady 480p feels better than a 1080p feed that stutters, so optimize for stability over sharpness.
• Low battery drain — 1 hour call should not drain more than 15-20% of battery. The camera, encoder, and radio are the big consumers, so most of the savings come from lowering resolution and staying on hardware codecs.
• Survives network changes (WiFi to LTE handoff). The call should recover in a second or two without dropping; this is the case where ICE restarts do the work (covered below).

Architecture

Two main models:

• P2P (peer-to-peer): direct connection between two devices. WebRTC handles the signaling and media. Used for 1:1 (FaceTime).
• SFU (Selective Forwarding Unit): all clients send/receive through a central server which forwards streams. Used for groups (Zoom).

Codecs

Audio: Opus (industry standard, 6–510 kbps adaptive).

Video: H.264 (universal compatibility), VP9, or AV1 (better compression, more CPU-expensive).

Modern apps negotiate the best codec available on both ends. Simulcast (sending multiple resolutions) is common for groups so the SFU can pick what to forward to each viewer based on their downlink.

Adaptive bitrate

WebRTC continuously measures network conditions:

• Packet loss. Rising loss means the network is congested and dropping data; the encoder should back off its bitrate before the connection collapses entirely.
• RTT (round-trip time). Growing RTT signals queues building up in the path (bufferbloat), which is an early cue to reduce the send rate before packets actually start dropping.
• Available bandwidth. Estimated from loss and RTT plus congestion-control feedback, this sets the ceiling for total send bitrate and is what the encoder targets.

Adjusts encoder bitrate accordingly. If bandwidth drops, video resolution drops first; audio is preserved at all costs.

Network handoff

If the user moves from WiFi to LTE (or vice versa), the IP address changes and the connection breaks unless ICE (Interactive Connectivity Establishment) renegotiates. WebRTC handles this with ICE restarts — a brief glitch but the call continues.

Echo cancellation and noise suppression

Native APIs do most of the work — iOS AVAudioEngine and Android AudioEffect. For high-quality, ML-based noise suppression (Krisp, RTX Voice, Apple Voice Isolation) runs on-device.

Background mode

iOS: declare voIP background mode. Audio continues; video pauses. PushKit can wake the app for incoming calls.

Android: foreground service required for ongoing calls. Notification badge keeps the call alive.

Battery optimization

• Use hardware-accelerated encoders (VideoToolbox on iOS, MediaCodec on Android)
• Lower video resolution when device is hot or battery is low
• Audio-only fallback when bandwidth is very poor

Frequently Asked Questions

Why does Zoom use a server (SFU) and not pure P2P for groups?

Pure mesh P2P does not scale — each client would need to upload N-1 streams. SFU centralizes the fan-out and allows simulcast, end-to-end encryption is harder but possible.

How does FaceTime achieve such low latency?

Heavy codec optimization, P2P when possible, Apple-controlled silicon for hardware acceleration, and integration with the OS for scheduling.

What is the right approach for E2EE in group calls?

SFU forwards encrypted media without decrypting. Each participant has a pairwise key with every other participant (or a group key with rotation on join/leave). Adds complexity but increasingly standard.