Problem Statement: A Guild-Centered Real-Time Communication Platform
Frames Discord as a server/channel community platform with real-time text, voice, presence, and a bot ecosystem, not a follower-graph social network.
Problem statement
Design a community communication platform organized into servers (guilds), each containing text and voice channels, with role-based permissions, rich presence, and a bot/integration framework. Unlike follower-graph networks such as Twitter or Facebook, Discord's fan-out unit is the guild: a message written in a channel must reach every online member of that guild who can read the channel, and a voice participant must hear every other participant with conversational latency.
Public evidence shows the category operates at extreme scale. Discord reports over 200 million monthly active users and 90M+ daily active users across millions of communities. Its engineering blog describes an Elixir gateway that scaled from 5 million to 11 million concurrent users, and an Elixir/Erlang platform pushing more than 26 million WebSocket events per second to clients at 12M+ concurrent users. Message persistence grew from a single MongoDB replica in 2015 to Cassandra and then ScyllaDB storing trillions of messages, and voice is handled by a custom WebRTC SFU architecture that handled 2.5 million concurrent voice users as early as 2017.
Why the problem is distinctive
Four planes make this design different from a generic chat backend. The messaging plane must fan out one write to potentially hundreds of thousands of online members with per-channel permission filtering. The voice plane is UDP/WebRTC with regional media relays, not REST. The presence plane broadcasts status and activity changes to everyone who shares a guild or friendship. The platform plane lets millions of third-party bots consume gateway events and respond through rate-limited APIs and signed HTTP interactions.
A strong interview answer therefore never says "use a message queue and WebSocket." It separates text fan-out, voice transport, presence propagation, and bot consumption, because each has a different consistency model, latency budget, and failure behavior.
The four architectural planes
- Messaging plane: durable message store, edit/delete propagation, search index, read states, notifications.
- Voice/video plane: signaling, SFU media relay, Opus codec, DAVE end-to-end encryption, region routing.
- Presence/social plane: online/idle/DND status, game activity, relationship and member list projections.
- Platform plane: bot gateway sharding, HTTP interactions with ed25519 signatures, OAuth2, webhooks, rate limits.
The attached brief requires server/channel structure with roles and permissions, real-time voice and low-latency text, rich presence, and bot frameworks. Every section of this answer maps back to one of those requirements plus the non-functional targets of concurrency, global latency, scalable identity, and spike resilience.
Key Highlights
- •Discord's fan-out unit is the guild/channel, not a follower graph; one write can target hundreds of thousands of online members.
- •Public scale anchors: 200M+ MAU, 12M+ concurrent users, 26M WebSocket events/sec to clients, trillions of stored messages, 2.5M concurrent voice users on WebRTC SFUs.
- •Four planes—messaging, voice, presence, platform—each need a different consistency and latency model.
- •Message storage evolved MongoDB (2015) to Cassandra to ScyllaDB; gateway is Elixir/Erlang with Rust for hot paths.
- •Bots are first-class consumers: sharded gateway sessions plus signed HTTP interactions.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate text fan-out, voice transport, presence, and bot consumption before choosing any technology."
- "I will treat published Discord numbers as context and label my own capacity targets as assumptions."