Bird
Raised Fist0

Design a Video Calling System - WebRTC, Signaling Server, Media Server

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Video Calling System - WebRTC, Signaling Server, Media Server
Design a scalable, low-latency video calling system using WebRTC with signaling and media servers
hardCommunication and Messaging SystemsFreq: high
Prerequisites:System Design FundamentalsCAP TheoremNetworking BasicsReal-time Communication Protocols
⚙️
Functional Requirements
  • Establish peer-to-peer video/audio calls using WebRTC with signaling server coordination
  • Support multi-party group calls with media server mixing or forwarding
  • User presence and call state management (call initiation, ringing, accept/reject, hangup)
  • Call recording and playback support (optional)
  • Real-time network quality monitoring and adaptive bitrate streaming
  • Cross-platform support (web, mobile browsers, native apps)
📊
Non-Functional Requirements
  • Support 50 million concurrent calls globally at peak
  • End-to-end latency under 150ms for 1:1 calls, under 300ms for group calls (P99)
  • System availability 99.99% with graceful degradation
  • Signaling message delivery within 100ms P99
  • Media server bandwidth capacity to handle 10 Tbps outbound traffic
❓
Clarifying Questions to Ask
  • What is the maximum supported group call size?
  • Is call recording mandatory or optional?
  • Should the system support NAT traversal and firewall bypass?
  • What are the expected geographic regions and data residency requirements?
  • Is end-to-end encryption required or is media server decryption allowed?
  • What is the expected average call duration and daily call volume per user?
Out of Scope
✗ User authentication and authorization mechanisms
✗ Video encoding/decoding codec implementation details
✗ UI/UX design of the calling interface
✗ Billing and payment integration
📌
Assumptions
  • 50 million concurrent calls at peak
  • Average call duration 5 minutes
  • Average signaling messages per call: 20 (setup, ICE, SDP, control)
  • Average media bitrate per user: 1 Mbps outbound
  • Retention period for call metadata: 30 days
⚡
QPS Calculation
write qps50M calls × 20 signaling msgs / (5 × 60) sec ≈ 3.33M writes/sec
peak write qpsAssuming 2× peak factor for bursts: 6.66M writes/sec
read qpsAssuming 2 reads per signaling message for state sync: 6.66M reads/sec
💾
Storage Estimate
daily storage3.33M writes/sec × 86400 sec × 1 KB/msg ≈ 287 TB/day
retention storage287 TB/day × 30 days = 8.6 PB
with replication8.6 PB × 3 replicas = 25.8 PB total
🖥️
Server Estimate
signaling serversEach signaling server handles 10K QPS → 6.66M / 10K = 666 servers
media serversEach media server supports 1 Gbps → 100 Tbps / 1 Gbps = 100,000 servers
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |   Clients   |
          +------+------+
                 |
          +------+-------+
          | Signaling    |
          | Servers     |
          +------+-------+
                 |
          +------+-------+
          | Media Server |
          | Cluster     |
          +------+-------+
                 |
          +------+-------+
          |   Database   |
          +--------------+
🧩
Components
Clients
Web or mobile apps implementing WebRTC stack for peer connection and media capture
Why thisWebRTC is the industry standard for real-time peer-to-peer media with NAT traversal and adaptive bitrate
Why notCustom RTP implementations lack browser support and require complex NAT traversal logic
Signaling Servers
Coordinate session setup, ICE candidate exchange, SDP negotiation, and call state management
Why thisStateless horizontally scalable WebSocket servers with Redis for presence and state enable low-latency signaling
Why notHTTP polling is too high-latency and inefficient for real-time signaling
Media Servers
Mix or forward media streams for group calls, record calls, and perform transcoding if needed
Why thisUsing Kurento or Jitsi Videobridge provides scalable SFU/MCU capabilities with media processing APIs
Why notPure P2P does not scale for large groups and lacks recording/transcoding support
Database
Store call metadata, user presence, and signaling state with high write throughput and low latency
Why thisApache Cassandra supports linear write scalability and multi-datacenter replication for 6.66M writes/sec
Why notPostgreSQL requires manual sharding and cannot sustain millions of writes per second
Load Balancer
Distribute client signaling connections evenly across signaling servers
Why thisLayer 7 load balancers like NGINX or Envoy support sticky sessions and WebSocket proxying
Why notDNS round-robin lacks session affinity causing signaling disruptions
🔄
Data Flow
1
Client A → Signaling Server
Send call initiation request with SDP offer
Signaling server validates and forwards to Client B
2
Signaling Server → Client B
Deliver call invitation and SDP offer
Client B responds with SDP answer
3
Client B → Signaling Server
Send SDP answer and ICE candidates
Signaling server relays to Client A
4
Clients A & B → Media Server (if group call)
Establish media streams via TURN or SFU
Media server mixes or forwards streams for group calls
5
Signaling Server → Database
Persist call state and metadata
Enables call history and recovery
6
Media Server → Storage
Store recorded media segments
For call recording and playback

Practice

(1/5)
1. A food delivery system must efficiently match nearby drivers to new orders in real-time, minimizing latency and ensuring fairness. Which component is best suited to handle this driver assignment under high load?
easy
A. A relational database with spatial indexing to query nearest drivers synchronously
B. A simple REST API that queries all drivers and filters by distance on the client side
C. A batch job that runs every 5 minutes to assign drivers to pending orders
D. A distributed in-memory geospatial index with pub/sub notifications for driver availability

Solution

  1. Step 1: Identify driver assignment requirements

    Real-time, low-latency matching requires fast spatial queries and event-driven updates.

  2. Step 2: Evaluate component suitability

    Relational DBs with spatial indexes (A) are too slow for high write/read concurrency; batch jobs (C) introduce unacceptable delay; client-side filtering (D) is inefficient and inconsistent.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Distributed in-memory geospatial index with pub/sub -> real-time, scalable driver assignment [check]
Hint: In-memory geospatial + pub/sub for real-time driver matching [check]
Common Mistakes:
2. A social media platform must handle 1 million new posts per second and fan-out updates to millions of followers asynchronously. Which component is best suited to decouple the high write throughput from the fan-out delivery process?
easy
A. Use a cache like Redis to store all posts and push updates directly
B. Use a relational database with triggers to notify followers synchronously
C. Use a distributed message queue like Kafka partitioned by user ID
D. Use a polling mechanism where followers fetch updates periodically

Solution

  1. Step 1: Identify the need for decoupling writes and fan-out

    Relational DB triggers (A) cause synchronous blocking and don't scale to 1M writes/sec. Redis (C) is fast but lacks durability and ordering guarantees for fan-out. Polling (D) adds latency and load on clients.

  2. Step 2: Evaluate Kafka for asynchronous, durable, partitioned messaging

    Kafka partitions by user ID to preserve ordering per user and decouples writes from fan-out delivery, handling high throughput efficiently.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Kafka partitions enable scalable, ordered fan-out delivery [check]
Hint: Kafka partitions decouple writes and preserve ordering [check]
Common Mistakes:
3. In the request flow, at Step 4 the CDN edge server checks its cache for the requested asset. What happens if the asset is not found in the cache?
easy
A. The CDN edge server returns a 404 error immediately to the client
B. The CDN edge server redirects the client to the origin server URL
C. The CDN edge server serves a stale cached version without contacting origin
D. The CDN edge server forwards the request to the origin server to fetch the asset

Solution

  1. Step 1: Trace CDN cache miss handling at Step 4

    When the asset is missing in the edge cache, the CDN must retrieve it from the origin server.

  2. Step 2: Confirm CDN forwards request to origin server for fresh content

    The CDN edge server acts as a proxy, fetching the asset from origin to serve the client.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Cache miss triggers origin fetch, not error or redirect [check]
Hint: Cache miss -> fetch from origin server, not error or redirect [OK]
Common Mistakes:
4. For propagating trace context across asynchronous messaging systems, which approach best preserves trace continuity without coupling services tightly?
medium
A. Embed trace context in message metadata headers supported by the messaging system
B. Use HTTP headers to propagate trace context in message payloads directly
C. Store trace context in a centralized database and have consumers query it on message receipt
D. Generate new trace IDs at each service and correlate offline during analysis

Solution

  1. Step 1: Understand asynchronous trace context propagation

    Embedding trace context in message metadata headers leverages messaging system features to propagate context without modifying payload or tight coupling.

  2. Step 2: Evaluate other options

    HTTP headers don't exist in messaging protocols. Centralized DB lookup adds latency and coupling. Generating new trace IDs breaks trace continuity and requires complex offline correlation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Message metadata headers preserve trace context asynchronously [check]
Hint: Use message metadata headers, not payload or DB lookup [OK]
Common Mistakes:
5. Without the event store (Kafka) in the system, what exactly breaks during command processing?
medium
A. Commands are processed twice causing duplicate events
B. Commands block until query model updates, causing high latency and no durability
C. Commands fail silently without any error notification
D. Commands are queued but never delivered to the read model

Solution

  1. Step 1: Identify event store role in command processing

    The event store (Kafka) durably persists events and decouples command processing from read model updates.

  2. Step 2: Trace failure without event store

    Without Kafka, commands have no durable event persistence, causing silent failures as events are lost without notification.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    No event store -> commands lost silently, no durability [check]
Hint: No event store -> silent command loss, no durability [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard