Design WebRTC-Based Chat

Hard45 min
1 / 30
System design answer

Design WebRTC-Based Chat

Hard45 min30 sections
understanding•8 min read

Problem Statement: Direct Browser-to-Browser Real-Time Communication

Frames WebRTC chat as a peer-to-peer media and data problem with a thin signaling plane, not a traditional client-server messaging system.

Problem Statement

Design a system that allows browsers to establish direct audio, video, and data-channel chat with minimal server overhead for relay. The system must handle ICE negotiation, NAT traversal via STUN/TURN servers, and provide real-time communications once peers connect. This is fundamentally different from traditional WebSocket-based chat because the media path bypasses the server entirely after connection establishment.

WebRTC (Web Real-Time Communication) is a collection of protocols and APIs that enables direct peer-to-peer communication between browsers. The W3C and IETF standardized the core protocols between 2011 and 2021, with RFC 8826 defining the security considerations and RFC 8827 defining the WebRTC security architecture. The key insight is that WebRTC separates the signaling plane (how peers discover and negotiate with each other) from the media plane (how audio, video, and data actually flow between peers).

Why This Problem Is Distinctive

A traditional chat system routes every message through a central server. WebRTC inverts this: the server exists only to introduce peers to each other, then steps aside. The media flows directly between browsers using UDP, encrypted with DTLS-SRTP. This creates three hard problems that do not exist in server-mediated architectures:

  1. NAT Traversal: Most devices sit behind NATs (Network Address Translators) that block inbound UDP. The system must discover the public IP:port mapping and punch through NATs using STUN, or relay through TURN when traversal fails.
  1. Signaling Complexity: WebRTC deliberately does not standardize signaling. The system must design its own protocol for exchanging SDP offers/answers and ICE candidates between peers who have no existing connection.
  1. Asymmetric Network Conditions: Two peers may have vastly different bandwidth, latency, and NAT types. The system must adapt codec selection, bitrate, and relay decisions per-connection.

The Four Architectural Layers

  1. Signaling Layer: WebSocket-based server that brokers SDP exchange and ICE candidate trickle between peers. Stateless, horizontally scalable.
  2. NAT Traversal Layer: STUN servers for address discovery, TURN servers for relay fallback when symmetric NATs block direct paths.
  3. Media Transport Layer: RTP/RTCP for audio and video, SCTP-over-DTLS for data channels, all encrypted with DTLS-SRTP.
  4. Application Layer: User management, room management, presence, and the chat UI that ties everything together.

Public Operating Baseline

Discord reported over 150 million monthly active users in 2023, with voice channels handling millions of concurrent connections. Their engineering blog describes a custom Selective Forwarding Unit (SFU) architecture built on WebRTC foundations. Google Meet serves over 100 million daily meeting participants and uses WebRTC natively in Chrome. Whereby, a WebRTC-first video platform, operates with a serverless signaling architecture where the browser handles all media directly. LiveKit, an open-source WebRTC infrastructure provider, reports handling millions of concurrent connections for customers including e-commerce, telehealth, and gaming companies.

Design Assumptions for This Interview

All uncited scale figures in this answer are explicit design assumptions:

  • 50 million registered users
  • 5 million daily active users
  • 200,000 concurrent peer connections at peak
  • 1 million signaling messages per day
  • 5x peak multiplier for events or outages
  • Average call duration: 12 minutes
  • 70% audio-only, 25% video, 5% data-channel-only
  • 15% of connections require TURN relay due to symmetric NAT

Key Highlights

  • •WebRTC separates signaling (server-mediated) from media (peer-to-peer), creating a thin server footprint.
  • •NAT traversal via STUN/TURN/ICE is the hardest networking problem, affecting 15-20% of connections.
  • •DTLS-SRTP provides mandatory end-to-end encryption for all media without server involvement.
  • •The signaling server is stateless and horizontally scalable; media never touches it after handshake.
  • •Discord, Google Meet, Whereby, and LiveKit all production-prove WebRTC at 100M+ user scale.
Lead With the P2P Insight
State in the first two minutes that after signaling, media flows directly between browsers with zero server involvement. This immediately distinguishes WebRTC from WebSocket-based chat and shows you understand the fundamental architecture.
Do Not Ignore NAT
A design that assumes direct IP connectivity between browsers fails for 15-20% of users behind symmetric NATs. Always include STUN/TURN/ICE as first-class components, not afterthoughts.

Section Rescue Kit

Buzzwords to use:

Signaling PlaneICE Candidate

Safe statements:

  • "I will separate the signaling plane from the media plane because they have fundamentally different scaling and reliability requirements."
  • "Before selecting technologies, let me define which operations happen server-side versus peer-to-peer."
Design WebRTC-Based Chat - System Design | WinJob | WinJob