Discord

Overview

Discord is a communication platform originally built for gaming communities, now serving 200M+ monthly active users across diverse interest groups. Its architecture is uniquely optimized for low-latency voice chat alongside text messaging, supporting millions of concurrent voice connections. Discord pioneered guild-based sharding, built its real-time infrastructure on Elixir/Erlang, and migrated its message storage from MongoDB to ScyllaDB to handle trillions of messages. The platform’s bot ecosystem and rich presence system are integral architectural components.

Scale

Requirements

High-Level Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Guild Sharding and Snowflake IDs

Discord’s core scaling strategy is guild-based sharding. Each guild (server) is assigned to a specific shard, and all operations for that guild are routed to the same set of backend processes.

Snowflake IDs: Discord uses Twitter-style Snowflake IDs — 64-bit integers encoding a timestamp, worker ID, and sequence number. This provides globally unique, time-ordered, and roughly sortable IDs without coordination. Message IDs are Snowflakes, enabling efficient range queries (“fetch messages before this ID”).

Gateway sharding: For large bots, Discord requires bot connections to be sharded — each shard handles events for a subset of guilds. The shard for a guild is determined by (guild_id >> 22) % num_shards.

Large guilds: Guilds with 100K+ members use lazy member loading — the client doesn’t receive the full member list on connect. Instead, members are loaded on-demand as the user scrolls the member sidebar or types @mentions.

Loading diagram...

MongoDB to ScyllaDB Migration

Discord stored messages in MongoDB for years but hit scaling limits as the platform grew to trillions of messages.

Problems with MongoDB:

• Hot partitions on popular channels caused latency spikes
• Compaction storms during off-peak hours degraded performance
• Memory-mapped storage engine was unpredictable under pressure

Why ScyllaDB?: A C++ rewrite of Cassandra offering better tail latencies and more predictable performance. Its shard-per-core architecture eliminates coordination overhead.

Data model: Messages are partitioned by channel_id with message_id (Snowflake) as the clustering key. This means fetching recent messages in a channel is a single partition scan in reverse order — extremely efficient.

Migration strategy: Discord ran dual-writes to both MongoDB and ScyllaDB, validated consistency, then cut over reads. The migration handled trillions of messages with zero downtime.

Voice Architecture and SFU Design

Discord’s voice is one of its biggest differentiators — it needs to feel instant, like sitting in a room together.

SFU model: Each voice channel is assigned a Selective Forwarding Unit (SFU) server. The SFU receives encoded audio from all participants and selectively forwards each participant’s stream to others. No transcoding happens server-side, keeping latency minimal.

Opus codec: All voice is encoded using Opus at 64kbps (adjustable). Opus provides excellent quality at low bitrates and has near-zero algorithmic delay (~26.5ms).

Voice activity detection: The SFU uses server-side VAD to determine who is speaking. Only active speakers’ audio is forwarded at full rate — silent participants send minimal keep-alive frames.

Region selection: Voice servers are deployed in 15+ regions. When a voice channel is created, the server closest to the majority of participants is selected. Users can override this with a per-channel region setting.

Priority speaker: In large voice channels, admins can enable priority speaker mode, which uses server-side mixing to attenuate other participants’ audio.

Loading diagram...

Architectural Tradeoffs

# Learn From a Discord-like System

You are an expert software architect and teacher. I want to learn from a Discord-inspired system design (Real-time voice, video, and text for communities at massive scale) without pretending this is the exact private production architecture.

Use the following reference as a learning model. Keep assumptions visible, avoid unsupported scale claims, and explain the engineering forces behind each design choice.

---

## System Design Reference
import { Mermaid, Scale, ComponentList, ComponentCard, Requirements, Tradeoff } from '@/components/mdx';

## Overview

Discord is a communication platform originally built for gaming communities, now serving 200M+ monthly active users across diverse interest groups. Its architecture is uniquely optimized for low-latency voice chat alongside text messaging, supporting millions of concurrent voice connections. Discord pioneered guild-based sharding, built its real-time infrastructure on Elixir/Erlang, and migrated its message storage from MongoDB to ScyllaDB to handle trillions of messages. The platform's bot ecosystem and rich presence system are integral architectural components.

## Scale

<Scale items={{
  "Monthly active users": "200M+",
  "Concurrent voice connections": "10M+",
  "Messages per day": "4B+",
  "Servers (guilds)": "19M+ active",
}} />

## Requirements

<Requirements
  functional={[
    'Guild-based text channels with categories',
    'Low-latency voice and video channels',
    'Screen sharing and Go Live streaming',
    'Rich presence and activity status',
    'Bot framework and application commands',
    'Role-based permissions at guild, category, and channel level',
    'Direct messages and group DMs',
  ]}
  nonFunctional={[
    'Ultra-low voice latency (<50ms codec-to-ear)',
    'High availability for voice infrastructure',
    'Horizontal scaling to millions of concurrent guilds',
    'Sub-second message delivery globally',
    'Support for guilds with 1M+ members',
    '...

[Full prompt copied to clipboard]