Discord Real-time Communication
How Discord scales real-time messaging to millions of concurrent users using Elixir and distributed systems.
What is Discord real-time communication architecture?
Discord real-time communication architecture is the collection of persistent gateways, channel services, durable message storage, fan-out workers, and presence systems that keeps a community conversation synchronized across connected devices.
In plain language: one person sends a message once, the system decides whether it is allowed, gives it a position in that channel, saves it, and delivers it to the right online sessions. A reconnect or retry must not create a second visible message or place a newer reply before an older one.
Core invariant
Every accepted message has one stable identity and one position in its channel before fan-out begins. Delivery may retry, but retries must not duplicate the visible message or violate per-channel order.
This case study uses an illustrative envelope of 80K accepted messages per second, 24 online recipient sessions per message, and a 250 ms P99 connected-delivery target. These are design inputs, not claims about Discord's current production traffic. Review WebSocket first if persistent bidirectional sessions and reconnects are new.
The product promise is an ordered, recoverable channel conversation
A text message has two user-visible moments. The sender needs an honest acknowledgement that the message was accepted, and recipients need prompt delivery in the same channel order. Those moments should be related by durable state, not one distributed transaction through every connected device.
Functional requirements
- Send, edit, and delete messages after checking server, channel, and user permissions.
- Deliver accepted messages to online channel subscribers and make missed messages available after reconnect.
- Synchronize a user's open sessions across desktop, web, and mobile without duplicate display.
- Expose typing and online status as useful hints without treating them as message history.
- Support direct messages and community channels while isolating a hot channel from unrelated conversations.
Non-functional requirements
- Acknowledge only authorized messages that have crossed the durable acceptance boundary.
- Deliver to connected recipients within 250 ms P99 during the planning envelope.
- Preserve one monotonic order per channel; do not coordinate unrelated channels through one global sequence.
- Survive gateway reconnects and at-least-once retries through stable message IDs and replay cursors.
- Bound fan-out queue age and degrade ephemeral work before durable message delivery.
Scope boundary
This design covers text messages, session gateways, channel ordering, fan-out, reconnect replay, and presence degradation. Voice, video, screen sharing, search ranking, moderation policy design, and attachment processing use separate paths with different latency and storage contracts.