Bird
Raised Fist0

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

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Clients

Initiate call signaling

Client sends SDP offer via WebSocket to signaling server

Protocol:WebSocket
BeforeClient has local SDP offer ready to send
AfterSDP offer sent to signaling server, waiting for answer
Load Balancer

Route WebSocket message

Load balancer forwards signaling message to an available signaling server

Protocol:WebSocket
BeforeSignaling server has no pending message from client
AfterSignaling server receives SDP offer from client
Signaling Servers

Process signaling and query DB

Signaling server validates session and fetches callee info from database

Protocol:REST API
BeforeSignaling server has SDP offer, no session info loaded
AfterSession info loaded, ready to forward offer to callee
Signaling Servers

Forward signaling to callee

Send SDP offer to callee client via WebSocket

Protocol:WebSocket
BeforeCallee client not yet notified of incoming call
AfterCallee client receives SDP offer, prepares answer
Media Servers

Establish media relay

Media servers allocate resources and relay media streams between clients

Protocol:WebRTC media channels
BeforeNo media streams established between clients
AfterMedia streams flowing through media servers for call
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│    Clients    │
└───────┬───────┘
        │ WebSocket (Signaling)
        ▼
┌───────────────┐
│ Load Balancer │
└───────┬───────┘
        │ WebSocket
        ▼
┌────────────────────┐
│  Signaling Servers  │
│ - Handle signaling  │
│ - Manage session    │
│   state             │
└───────┬────────────┘
        │ REST API (DB)
        ▼
┌───────────────┐
│   Database    │
│ - Store user  │
│   & session   │
│   info        │
└───────────────┘
        ▲
        │ WebSocket (Media Ctrl)
        │
┌───────────────┐
│ Media Servers │
│ - Relay media │
│ - Transcode   │
│ - Mix streams │
└───────────────┘
Design Rationale

This architecture shows a vertical flow from Clients initiating signaling via WebSocket, through a Load Balancer that distributes connections to Signaling Servers. The Signaling Servers handle session negotiation and query the Database for user info. Once signaling completes, Media Servers relay and process the actual media streams between clients. This separation ensures signaling and media handling are decoupled, allowing scalable session management and efficient media processing. The Load Balancer prevents signaling server overload by distributing connections. The Database stores persistent session metadata but is not in the media path, avoiding bottlenecks. Media Servers handle real-time media relay and transcoding, critical for multi-party calls and network adaptation.

Primary Focus

✓

Practice

(1/5)
1. A distributed database system needs to evenly distribute data across 100 shards and handle dynamic addition/removal of shards with minimal data movement. Which component is most appropriate to manage shard assignment?
easy
A. Use a modulo-based hash function on the primary key to assign shards directly
B. Implement consistent hashing with virtual nodes to map keys to shards
C. Assign shards based on a centralized lookup table updated on every shard change
D. Use range-based partitioning with fixed key ranges per shard

Solution

  1. Step 1: Understand shard assignment requirements

    Modulo hashing (Use a modulo-based hash function on the primary key to assign shards directly) causes massive remapping when shards change; centralized lookup (Assign shards based on a centralized lookup table updated on every shard change) creates a bottleneck and single point of failure; range partitioning (Use range-based partitioning with fixed key ranges per shard) can cause hotspots and uneven load.

  2. Step 2: Evaluate consistent hashing benefits

    Consistent hashing with virtual nodes (Implement consistent hashing with virtual nodes to map keys to shards) evenly distributes keys and minimizes remapping when shards are added or removed, making it ideal for dynamic shard management.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Consistent hashing minimizes shard remapping on topology changes [check]
Hint: Consistent hashing minimizes data movement on shard changes [OK]
Common Mistakes:
2. A distributed task scheduler must support millions of scheduled jobs with varying priorities and ensure tasks are executed exactly once. Which component is best suited to manage task ordering and priority under these constraints?
easy
A. A distributed priority queue with partitioned shards
B. A relational database with indexed priority columns
C. A simple FIFO message queue like RabbitMQ without priority support
D. A cron job scheduler running independently on each node

Solution

  1. Step 1: Identify priority and scale requirements

    A relational DB (A) struggles with high write throughput and priority ordering at scale; simple FIFO queues (C) lack priority support; cron jobs (D) do not coordinate distributed execution or priority.

  2. Step 2: Evaluate distributed priority queue

    A distributed priority queue with partitioned shards (B) can scale horizontally, maintain priority ordering per shard, and support exactly-once execution semantics.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Distributed priority queue shards scale and preserve ordering [check]
Hint: Distributed priority queues scale and order tasks by priority [check]
Common Mistakes:
3. In the web crawler's request flow, at Step 5 the Duplicate Detection component receives a URL. What happens if this URL has been seen before?
easy
A. The URL is discarded and not sent to the Scheduler to avoid redundant crawling
B. The URL is immediately re-queued to the Scheduler for crawling again
C. The URL is marked for delayed re-crawl but still sent to the Scheduler
D. The URL is sent to the Politeness Policy Manager to check domain delays

Solution

  1. Step 1: Understand Duplicate Detection behavior at Step 5

    If the URL has been seen before, it is filtered out to prevent redundant crawling.

  2. Step 2: Eliminate other options

    Re-queuing duplicates wastes resources; marking for delayed re-crawl is a separate process; Politeness Policy Manager handles timing, not duplication.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Duplicate Detection discards seen URLs to avoid redundancy [check]
Hint: Duplicate Detection discards duplicates before scheduling [OK]
Common Mistakes:
4. Without Kafka in the architecture, what exactly breaks in the message delivery flow when Alice sends a message to Bob?
medium
A. Delivery receipts are sent out of order causing UI inconsistencies
B. Alice's message is encrypted incorrectly causing decryption failures on Bob's side
C. Alice's send blocks until Bob's server responds; if Bob's server crashes, message is lost with no retry
D. Messages are duplicated because of lack of idempotent writes

Solution

  1. Step 1: Understand Kafka's role in decoupling send and delivery

    Kafka buffers messages asynchronously; without it, Chat Server must synchronously contact Bob's server.

  2. Step 2: Trace failure without Kafka

    If Bob's server is slow or crashes, Alice's send blocks or message is lost with no retry, breaking reliability.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    No Kafka -> synchronous send blocks, message loss on Bob's crash [check]
Hint: No Kafka -> synchronous send blocks, no retry, message lost [check]
Common Mistakes:
5. At 10x scale, which component in a sharded CRDT distributed counter system is most likely to fail first and why?
hard
A. The shard replicas, because network partitions cause permanent state divergence without reconciliation
B. The replication layer, because increased shard count causes exponential message overhead saturating network bandwidth
C. The global aggregator node, because it becomes a bottleneck merging all shard states synchronously
D. The client-side counters, because local state grows unbounded without periodic compaction

Solution

  1. Step 1: Analyze scale impact on components

    Global aggregator (A) merges asynchronously, so less likely bottleneck. Replication overhead (C) grows but can be optimized. Client counters (D) can compact state.

  2. Step 2: Identify shard replicas failure mode

    At 10x scale, network partitions increase, causing shards to diverge permanently without reconciliation, breaking eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Network partitions cause shard divergence first at scale [check]
Hint: Network partitions cause shard divergence before aggregator bottlenecks [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