Zoom API Design

Zoom API design

Video conferencing applications like Zoom connect millions of users for remote collaboration through face-to-face meetings, screen sharing, and recording. Designing an API like this requires a deep understanding of networking, real-time media transport, and backend orchestration. This masterclass covers how Zoom meetings are scheduled, how resources are assigned for global streaming sessions, and how the overall architecture enables an efficient video conferencing API.

Functional requirements

• Managing meetings: The API allows hosts to initiate, schedule, update, and delete one-on-one or group meetings.

• Managing participants: The API allows hosts to add, remove, and restrict participants.

• Streaming data: The API allows participants to share screens and audio/video streams.

• Recording meetings: The API allows hosts to record meetings locally or in the cloud.

Nonfunctional requirements

• Availability and reliability: The API must remain available to end users; the system should function reliably even if some participants temporarily drop.

• Security: End-to-end encrypted communication, with mechanisms to handle spam attendees.

• Scalability: The service must handle a growing user base and concurrent requests.

• Latency: As a real-time application, the API must deliver content with minimal latency.

Prerequisites

This design builds on the pub-sub service, which notifies participants of events such as recording status, time limits, and guest join requests.

Real-time communication foundations

The internet's client-server model introduces inherent relay latency. For video conferencing, this is compounded by large data sizes and distant servers, resulting in glitchy playback when the path is suboptimal.

User-perceived latency depends primarily on transfer and processing time. Live streams require minimal processing but often traverse long distances. Solving this "extra miles" problem requires real-time communication techniques.

Real-time communication

The shortest data path is peer-to-peer, but this becomes problematic when participants sit behind different Network Address Translation (NAT)Network Address Translation (NAT) is the replacement of a user's private IP with an internet service provider's (ISP) public IP. areas. A signaling server resolves this by enabling both parties to exchange multimedia session descriptions containing ports, IP addresses, and other connection metadata.

Note: A multimedia session identifies media-related metadata essential for transmission, processing, and enabling device-specific features compatible with other participants.

Signaling and connecting

Signaling is the successful initiation of a multimedia session between participants. Before communication starts, clients must exchange and agree on session information (communication addresses, media descriptions, and metadata) via the Session Description Protocol (SDP).

SDP is a standardized description format delivered using protocols like Session Initiation Protocol (SIP) or Session Announcement Protocol (SAP)The Session Announcement Protocol is a set of rules for sharing session information among multicast groups. Users then listen to these well-known groups to receive session announcements..

Session Initiation Protocol (SIP)

SIP provides guidelines for peer-to-peer communication to share, maintain, and terminate audio/video conferences. It is not a complete vertical stackA set of protocols that work on top of each other to provide complete functionality. and works alongside protocols like RTPReal-time Transport Protocol is an application-layer protocol known for fast audio/video transmission using UDP as the transport protocol., RTSPThe Real-time Streaming Protocol is an application-layer protocol known for multiplexing control and data streams in real-time communications., and HTTP. SIP uses proxy servers for participant discovery, enables session negotiation via SDP, and supports adding and removing participants from multicast sessions.

The following illustration shows two clients exchanging session information via SIP signaling. Both clients agree to share data (steps one and two), but exchanging actual video frames requires establishing an interactive connection (step three):

Data exchange protocols

Several protocols provide bidirectional, endpoint-to-endpoint data flow: WebSockets, WebRTC, H.323H.323 is a protocol stack recommended by the ITU Telecommunication Standardization Sector (ITU-T) for multimedia broadcasting, but it is much more complex than its counterparts., and others. Among these, WebRTC is the most popular peer-to-peer video conferencing protocol stack. It is built on top of SRTPSecure Real-time Transport Protocol is a secure version of RTP with encryption and message authentication capabilities., SCTPThe Stream Control Transmission Protocol is a protocol designed for sending control messages reliably with built-in support for maintaining message boundaries., DTLSDatagram Transport Layer Security is a protocol designed to secure UDP-based communications at the transport layer., and others. Originally developed for browser-based multimedia conferencing, it later gained native application support across platforms.

While peer-to-peer protocols like WebRTC enable powerful real-time data transfer, they introduce scaling challenges.

Scaling real-time communication

SIP handles session exchange, and WebRTC handles data exchange, but neither alone provides a scalable conferencing solution. Peer-to-peer connections work for small groups (five to 10 participants), but beyond that, a full mesh becomes resource-intensive for each participant: