Discord became popular for gaming communities in the beginning but it’s now used by folks with varying interests. I also happen to own a Discord Server, Builders Lounge focused on System Design discussions.
One of the popular Discord feature is voice channels, aka audio-only channels. A channel can have millions of members and the system should ensure the user experience is optimal and system’s health is not degraded.
Today’s article is focused on the backend design of system responsible for managing the Discord voice servers. Let’s jump in.
High-Level Architecture
The first point of discussion is ‘How does people interact on Discord?’. There are two design possibilities.
Peer-to-Peer (P2P) Connection: User devices are connected to each other for communication.
Client-Server Architecture: User devices are connected to each other via a server in-between. Figure 1 shows facilitating user communication with a server.
Discord architecture is based on client-server model. The reasons to choose client-server over peer-to-peer are highlighted below.
Scalability: Peer-to-peer networking becomes exponentially expensive as the number of users increase.
IP Privacy & DDoS Protection: Routing all network traffic through Discord servers prevents exposing user IP addresses, protecting users from DDoS attacks.
Moderation: Admins can centrally manage permissions, such as muting or disabling audio/video for offending users.
Let’s detail out on client and server architecture.
Client Architecture
Choosing a right protocol is essential for efficient communication, considering near real-time connectivity between the users. Discord uses WebRTC (Web Real-Time Communication) for this purpose. A definition from wikipedia;
WebRTC provides web browsers/ mobile apps with real time communication via APIs. It allows audio/video communication to work inside webpages by allowing direct peer to peer communication, eliminating the need to install any plugin/download native apps.
BUT, we discussed peer-to-peer communication is slow for large user pools. Discord overcomes it with custom client-server implementation built on top of WebRTC. Let’s discuss in more detail.
Custom Implementation Details
As stated above, WebRTC has default implementation for peer-to-peer communication. To make it work and support connectivity via server, here are the key enhancements to protocol’s implementation.
Session Description Protocol (SDP) Optimization
Standard WebRTC uses SDP to negotiate audio/video metadata (~10 KB round-trip).
Discord uses the lower-level
webrtc::CallAPI to create send/receive streams directly. This cuts exchanged metadata down to ~1,000 bytes (server IP/port, encryption keys, codec, and stream IDs).
Bypassing Interactive Connectivity Establishment (ICE)
ICE is designed to find direct peer-to-peer paths through NATs/firewalls. Since all clients connect directly to Discord’s media relay servers, ICE is unnecessary.
Clients send periodic ping messages to keep firewall ports open.
Hides individual client IP addresses behind Discord’s relay servers.
Media Encryption & Bandwidth Optimization
Uses SRTP (Secure Real-time Transport Protocol) for media encryption.
Encryption keys are negotiated using DTLS (Datagram Transport Layer Security). Custom transport layers can be implemented via
webrtc::TransportAPI.Salsa20 encryption is used.
Silence suppression: No audio data is transmitted during silent periods, conserving client bandwidth and CPU usage.
Next, let’s move to the backend architecture.
Backend Architecture
There are number of core backend services (written in Elixir) responsible to handle the voice server workloads.
Discord Gateway Server (DGWS): Manages persistent WebSocket connections for online presence, guilds, channels, and text messages.
Discord Guilds Server (DGS): Manages guild state, channels, and voice server allocation.
Discord Voice Server (DVS): Relays audio/video streams across voice participants.