Design Zoom

What is Zoom?

Zoom is a video conferencing platform that provides high-quality video calls, screen sharing, recording, and meeting management for businesses, education, and personal use. It's similar to Microsoft Teams, Google Meet, or Cisco Webex but optimized for large-scale video conferencing and collaboration.

Large-scale video conferencing with screen sharing and recording is what makes systems like Zoom unique. By understanding Zoom, you can tackle interview questions for similar video platforms, since the core design challenges—video streaming, media processing, meeting management, and global scalability—remain the same.

Functional Requirements

Core (Interview Focussed)

• Video Conferencing: Users can join video calls with multiple participants and high-quality video.
• Screen Sharing: Share screens, applications, or specific windows with meeting participants.
• Meeting Management: Create, schedule, and manage meetings with participant controls.
• Recording: Record meetings with video, audio, and screen sharing content.

Out of Scope

• User authentication and account management
• Payment processing and subscriptions
• Mobile app specific features
• Third-party integrations
• Advanced analytics and reporting

Non-Functional Requirements

Core (Interview Focussed)

• Low latency: Video latency under 200ms globally.
• High availability: 99.9% uptime for video services.
• Scalability: Handle millions of concurrent video streams.
• Quality: Adaptive video quality based on network conditions.

Out of Scope

• Data retention policies
• Compliance and privacy regulations

💡 Interview Tip: Focus on low latency, high availability, and scalability. Interviewers care most about video streaming architecture, media processing, and meeting management.

Core Entities

💡 Interview Tip: Focus on Meetings, VideoStreams, and ScreenShare as they drive video conferencing, media processing, and scalability challenges.

Core APIs

Meeting Management

• POST /meetings { title, start_time, duration, max_participants } – Create meeting
• GET /meetings/{meeting_id} – Get meeting details
• POST /meetings/{meeting_id}/join – Join meeting
• POST /meetings/{meeting_id}/leave – Leave meeting
• PUT /meetings/{meeting_id}/settings – Update meeting settings

Video Streaming

• POST /meetings/{meeting_id}/streams { quality, resolution } – Start video stream
• PUT /streams/{stream_id}/quality – Update stream quality
• POST /streams/{stream_id}/mute – Mute/unmute video
• GET /meetings/{meeting_id}/participants – Get active participants

Screen Sharing

• POST /meetings/{meeting_id}/share { content_type } – Start screen sharing
• PUT /share/{share_id}/permissions – Update sharing permissions
• POST /share/{share_id}/stop – Stop screen sharing
• GET /meetings/{meeting_id}/active_shares – Get active shares

Recording

• POST /meetings/{meeting_id}/record – Start meeting recording
• POST /recordings/{recording_id}/stop – Stop recording
• GET /recordings/{recording_id} – Get recording details
• GET /users/{user_id}/recordings – List user's recordings

High-Level Design

Key Components

• Client Applications: Desktop, web, and mobile apps for Zoom
• API Gateway: Routes requests, handles authentication, and load balancing
• Meeting Service: Manages meetings, participants, and meeting settings
• Video Service: Handles video streaming and WebRTC coordination
• Screen Share Service: Manages screen sharing and content streaming
• Recording Service: Handles meeting recording and media processing
• Media Gateway: Manages WebRTC signaling and media routing
• Database: Stores meetings, users, recordings, and meeting data
• Cache: Redis for frequently accessed data and session management
• CDN: Delivers recorded content and static media files

Mapping Core Functional Requirements to Components

💡 Interview Tip: Focus on Video Service, Screen Share Service, and Recording Service; other components can be simplified.

Zoom Architecture

Data Modeling

💡Design Tips

• Use WebRTC for peer-to-peer video communication to reduce server load
• Implement adaptive bitrate streaming for different network conditions
• Cache active streams and screen shares in Redis for fast access
• Use CDN for recording playback and static content delivery
• Partition meetings by time and region for better scalability

Data Flow & Component Interaction

This diagram illustrates the data flow when users join meetings, start video streams, share screens, and begin recording in a Zoom-like system.

Meeting Join

• User requests to join a meeting
• Meeting Service validates access and retrieves meeting details
• Participant information is cached for fast access
• User receives meeting details and participant list

Video Stream Start

• User starts their video stream
• Video Service initializes WebRTC connection
• Stream information is cached for real-time access
• WebRTC signaling enables peer-to-peer video communication

Screen Sharing

• User starts screen sharing
• Screen Share Service manages content streaming
• Share session is tracked in cache
• Other participants receive screen share stream

Recording Start

• Host starts meeting recording
• Recording Service initializes media capture
• Recording metadata is stored in database
• All meeting content is captured for later playback

Key Design Highlights

• WebRTC: Enables peer-to-peer video communication with low latency
• Adaptive Streaming: Adjusts video quality based on network conditions
• Media Processing: Handles screen sharing and recording content
• Caching: Provides fast access to active streams and meeting data

Database Design

Database Choices

Primary Database: PostgreSQL

• Rationale: ACID compliance for meeting data, user management, and recordings
• Use Cases: Meetings, users, recordings, meeting rooms, settings
• Benefits: Strong consistency, complex queries, JSON support for flexible schemas

Stream Database: Redis

• Rationale: High-performance caching for real-time video streams and sessions
• Use Cases: Active streams, screen shares, participant sessions, meeting state
• Benefits: Sub-millisecond latency, pub/sub for real-time features

Recording Storage: S3 + CDN

• Rationale: Scalable object storage with global content delivery
• Use Cases: Meeting recordings, screen share content, media files
• Benefits: Unlimited storage, high durability, global distribution

Search Database: Elasticsearch

• Rationale: Full-text search for meetings, recordings, and user content
• Use Cases: Meeting search, recording search, content indexing
• Benefits: Fast text search, faceted search, real-time indexing

Table Design

Meetings Table (PostgreSQL)

Indexes:

• idx_meetings_host on host_id
• idx_meetings_start_time on start_time
• idx_meetings_url on meeting_url
• idx_meetings_status on status

Participants Table (PostgreSQL)

Indexes:

• idx_participants_meeting on meeting_id
• idx_participants_user on user_id
• idx_participants_active on is_active

Video Streams Table (Redis)

TTL: 2 hours (streams auto-expire)

Screen Shares Table (Redis)

TTL: 1 hour (shares auto-expire)

Recordings Table (PostgreSQL)

Indexes:

• idx_recordings_meeting on meeting_id
• idx_recordings_host on host_id
• idx_recordings_status on status
• idx_recordings_created on created_at

Users Table (PostgreSQL)

Indexes:

• idx_users_email on email
• idx_users_subscription on subscription_tier

Database Trade-offs

Consistency vs Availability

• Meetings and Users: Strong consistency required for meeting access and user management
• Video Streams: High availability prioritized for real-time communication
• Recordings: Eventual consistency acceptable for better performance and scalability

Performance vs Storage

• Stream Caching: Cache active streams in Redis for low latency, but requires memory management
• Recording Storage: Use CDN for fast playback vs. storage costs
• Index Optimization: More indexes improve query performance but increase storage and write overhead

Scalability vs Complexity

• Database Sharding: Shard by meeting_id for horizontal scaling, but adds complexity for cross-meeting operations
• Read Replicas: Improve read performance but require eventual consistency handling
• Microservices: Better scalability but increased operational complexity

Real-time Communication Architecture

WebRTC Implementation

WebRTC enables peer-to-peer video communication with low latency. The Media Gateway handles signaling and connection establishment, while actual video streams flow directly between clients.

Adaptive Streaming

Video quality automatically adjusts based on network conditions. The system implements adaptive bitrate algorithms to optimize quality while maintaining smooth playback.

Screen Sharing Management

Screen sharing uses WebRTC data channels for content streaming. The system manages sharing permissions and provides controls for hosts to manage shared content.

Scalability Considerations

Horizontal Scaling

The system implements horizontal scaling across all components. Microservices can be scaled independently based on demand. Load balancers distribute traffic across multiple service instances.

Database Scaling

Databases use read replicas and sharding strategies to handle large data volumes. Meetings are sharded by meeting ID, while user data uses user ID for distribution.

Video Stream Scaling

Video streams use WebRTC for peer-to-peer communication, reducing server load. Media Gateway instances handle signaling and connection management for multiple meetings.

Recording Scaling

Recordings are processed asynchronously and stored in object storage. CDN distribution ensures fast global access to recorded content.

Security Considerations

Communication Encryption

Video and audio streams are encrypted using WebRTC's built-in encryption. Meeting data is encrypted in transit using TLS and at rest using database encryption.

Access Control

Meeting access is controlled through passwords, waiting rooms, and participant management. Role-based permissions provide granular access control for different user types.

Content Protection

Recordings are encrypted and access-controlled. Screen sharing content is protected with permission controls and audit logging.

Monitoring and Analytics

Performance Monitoring

The system monitors key metrics including video latency, stream quality, and WebRTC connection success rates. Database performance metrics track query performance and connection usage.

User Analytics

User behavior analytics track meeting patterns, participation rates, and feature usage. Video quality analytics provide insights into network conditions and user experience.

System Analytics

System analytics track resource usage, error rates, and scaling metrics. Meeting analytics monitor concurrent sessions and bandwidth usage.

Trade-offs and Considerations

Latency vs Quality

Video communication prioritizes low latency over perfect quality. The system implements adaptive bitrate algorithms to optimize quality based on network conditions.

Scalability vs Features

Advanced features like recording and screen sharing add complexity but improve user experience. The system balances feature richness with scalability requirements.

Real-time vs Persistence

Real-time features require fast access patterns, while persistence ensures data durability. The system uses different storage strategies for different data types.

Future Enhancements

Advanced Video Features

Virtual backgrounds, noise cancellation, and AI-powered features can enhance the video experience. These features require additional processing infrastructure.

Collaboration Tools

Whiteboarding, document sharing, and real-time collaboration can improve meeting productivity. These features require additional infrastructure for content management.

AI Integration

AI-powered transcription, translation, and meeting summaries can enhance accessibility and productivity. These features require ML processing pipelines.

Interview Tips

Key Points to Cover

1. WebRTC Architecture: Explain peer-to-peer video communication and signaling protocols
2. Meeting Management: Discuss participant control, permissions, and meeting settings
3. Screen Sharing: Explain content streaming and permission management
4. Scalability: Discuss horizontal scaling strategies and media processing

Common Follow-up Questions

• How would you handle WebRTC connection failures and reconnection?
• What strategies would you use for video quality adaptation?
• How would you implement screen sharing permissions and controls?
• What approaches would you take for meeting recording and playback?

Red Flags to Avoid

• Not considering WebRTC architecture for video communication
• Ignoring screen sharing and recording complexity
• Overlooking meeting management and participant control
• Not addressing scalability challenges for millions of users