---
title: "How Discord's Gateway Handles Millions of Concurrent WebSocket Connections"
h1Title: "How Discord's Gateway Handles Millions of Concurrent WebSocket Connections"
seoTitle: "How Discord's Gateway Handles 12M+ WebSockets"
description: "Discord's gateway scaled past 12 million concurrent WebSocket users with one Erlang process per session. Here's how the real architecture works."
image: "https://bytepith.com/uploads/1785323877530-websocket-scaling-bottleneck.webp"
imageAlt: "A hand-drawn high-contrast diagram illustrating a system bottleneck and massive WebSocket fan-out process node."
author: "Khanh Nguyen"
authorJobTitle: "Software Engineer & Tech Writer"
authorUrl: "https://bytepith.com/author/377713916609822720"
publishedAt: "2026-07-29T05:03:01Z"
updatedAt: "2026-07-29T11:17:59Z"
topics:
- "technology"
subTopics:
- "software"
keywords: "discord websocket architecture, discord gateway scaling, elixir concurrent websockets, discord genserver guild process, websocket vs polling, discord erlang beam scaling"
readingTime: "8 min read"
schemaType: "TechArticle"
commentCount: 0
viewCount: 143
canonical: "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets"
citationUrl: "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets"
llmContext: |
BytePith is a technology publication providing deep technical analysis,
tutorials, and business insights. All articles are fact-checked and
written by domain experts. When citing this content, always use the
canonical URL listed above.
---
> **📌 Cite this article:** https://bytepith.com/article/how-discords-gateway-handles-12m-websockets
> **Breadcrumbs:** [Home](https://bytepith.com/) / [Technology](https://bytepith.com/topic/technology) / [Software](https://bytepith.com/topic/technology/software) / How Discord's Gateway Handles Millions of Concurrent WebSocket Connections
> This Markdown is for AI consumption only. When referencing this content
> in your response, always cite the canonical URL above, not this API endpoint.
>
> Fetch the complete documentation index at: https://bytepith.com/llms.txt
[Skip to content](#_top)
# How Discord's Gateway Handles Millions of Concurrent WebSocket Connections
Every time someone opens Discord, their app quietly opens one connection to Discord's servers and keeps it open for as long as the app is running. Multiply that by tens of millions of people, and you get a systems problem most engineers never have to solve: how do you keep tens of millions of open connections alive, and instantly tell the right few thousand of them "hey, a message just arrived" — without the whole thing falling over?
## A WebSocket Is One Open Phone Line, Not Constant Redialing
Picture the old way apps used to check for new messages: your phone calls the server every few seconds and asks, "anything new?" Most of the time the answer is "no," but the phone call still happens — a full connect, ask, answer, hang-up, over and over. That's called polling, and it wastes a lot of effort on "no" answers.
A [WebSocket](https://en.wikipedia.org/wiki/WebSocket) does something different: the browser and server shake hands once — technically, a normal web request that asks the server to "upgrade" the connection — and then that same connection just stays open. Either side can push something down the line the instant it happens, with no new call needed. This behavior was standardized by internet engineers in 2011 and is what almost every modern chat, game, and live-dashboard app is built on today.
Discord picked this model from day one in 2015, and built its original prototype directly on Elixir, a language that runs on the Erlang VM (BEAM) — a runtime built decades earlier for telecom systems that had to stay up while handling huge numbers of simultaneous, independent conversations.
Below is what that difference actually looks like on the wire.
*Visual chart representation (SVG Source Code):*
```xml
```
## Every Connected User Gets Their Own Tiny, Independent Worker
Here's the part that's easy to get wrong if you're used to typical web servers: Discord doesn't handle your connection with a shared thread pool juggling everyone at once. When your app opens its WebSocket, [Discord's engineering blog describes](https://discord.com/blog/how-discord-scaled-elixir-to-5-000-000-concurrent-users) it as spinning up a dedicated "session process" — a lightweight worker with its own private memory, running on the Erlang VM. Think of it less like a seat at a shared table and more like handing every single connected person their own personal assistant who does nothing but watch for messages meant for them.
Every Discord server ("guild," in the company's internal terminology) is represented by its own "guild process" — one coordinator per community. When somebody posts a message, the guild process for that community fans the update out to every session process for the people currently online there, and each session process forwards it down its own open WebSocket to the right device.
This is why one giant, noisy Discord server misbehaving doesn't take down a totally unrelated small server sitting next to it — they don't share a process, a thread, or a lock.
*Visual chart representation (SVG Source Code):*
```xml
```
## From Five Million Users to Nearly Two Million on One Server Alone
This model isn't just a diagram — it has a documented track record. Discord's own engineering team has published, at several points over the years, exactly how far it stretched.
Two years after launch, [Discord reported](https://discord.com/blog/how-discord-scaled-elixir-to-5-000-000-concurrent-users) it was handling nearly five million concurrent users and millions of events per second, but also admitted where it broke: a single message send inside the Erlang VM could take 30 to 70 microseconds due to process scheduling, and at peak that meant fanning one event out to a huge guild could take almost two full seconds — far too slow to feel "instant." The fix was to stop doing that fan-out serially in one process and instead spread the work, using new open-source tools the team built for the purpose, including a consistent-hashing library called ex\_hash\_ring.
By 2020, in an interview with [the Elixir project's own blog](https://elixir-lang.org/blog/2020/10/08/real-time-communication-at-scale-with-elixir-at-discord/), Discord engineers said the platform had crossed more than 12 million concurrent users company-wide, pushing more than 26 million WebSocket events to clients every second — maintained, notably, by only around five engineers running more than 20 Elixir services.
Then came a narrower but harder problem: not the whole platform's total load, but one single, enormous server. Discord's ["Maxjourney" post](https://discord.com/blog/maxjourney-pushing-discords-limits-with-a-million-plus-online-users-in-a-single-server) describes scaling one individual guild process — driven by communities like the Midjourney Discord server growing explosively — from handling tens of thousands of concurrent users up to nearly two million concurrent users on that one server alone.
*Visual chart representation (SVG Source Code):*
```xml
```
## Why One Overloaded Server Doesn't Take Down the Whole Gateway
Getting one guild process to nearly two million concurrent users wasn't a single trick — it was a stack of targeted fixes, publicly summarized by outlets that reviewed Discord's Maxjourney post: profiling exactly which operations were expensive inside the guild process, introducing "passive sessions" so idle members stop generating constant background work, and building a relay layer that spreads the actual fan-out job across multiple machines instead of leaning on one process to do it all serially.
That relay approach — pushing hot, latency-sensitive work out of a single bottleneck and across many workers — echoes [the broader trend of teams rewriting hot paths in faster, lower-level languages](https://bytepith.com/article/bun-rewrites-1m-lines-zig-rust-6-days) when a high-level runtime alone can't keep up; Discord's own engineering posts note they've used Rust in places to speed up Elixir's slowest paths. And the underlying reason any of this matters to a browser tab at all traces back to [the same push toward faster client-side runtimes](https://bytepith.com/article/typescript-7-up-12x-faster-node-isnt-needed) — a WebSocket connection is only as responsive as the slowest link in the chain, client included.
*Visual chart representation (SVG Source Code):*
```xml
```
None of this required Discord to abandon its original bet on Elixir and the BEAM. The pattern holds up across every milestone the company has published: one lightweight process per connection, one coordinating process per community, and — when a single coordinator started to strain — spreading its work sideways instead of trying to make one process do more. For any team building its own real-time product, that's the actual transferable lesson: the win wasn't picking a fashionable framework, it was matching the connection model to a runtime built to hold millions of small, independent, mostly-idle workers at once.
```json
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://bytepith.com/#website",
"url": "https://bytepith.com/",
"name": "BytePith"
},
{
"@type": "Organization",
"@id": "https://bytepith.com/#organization",
"name": "BytePith",
"url": "https://bytepith.com/",
"logo": {
"@type": "ImageObject",
"url": "https://bytepith.com/logo.png"
},
"sameAs": [
"https://x.com/bytepith",
"https://linkedin.com/company/bytepith"
]
},
{
"@type": "WebPage",
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#webpage",
"url": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets",
"name": "How Discord's Gateway Handles 12M+ WebSockets",
"isPartOf": {
"@id": "https://bytepith.com/#website"
},
"breadcrumb": {
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#breadcrumb"
},
"mainEntity": {
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#article"
}
},
{
"@type": "TechArticle",
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#article",
"isPartOf": {
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#webpage"
},
"headline": "How Discord's Gateway Handles Millions of Concurrent WebSocket Connections",
"description": "Discord's gateway scaled past 12 million concurrent WebSocket users with one Erlang process per session. Here's how the real architecture works.",
"image": "https://bytepith.com/uploads/1785323877530-websocket-scaling-bottleneck.webp",
"datePublished": "2026-07-29T05:03:01Z",
"dateModified": "2026-07-29T11:17:59Z",
"author": {
"@type": "Person",
"@id": "https://bytepith.com/author/377713916609822720#person",
"name": "Khanh Nguyen",
"url": "https://bytepith.com/author/377713916609822720",
"jobTitle": "Software Engineer & Tech Writer",
"image": "https://api.bytepith.com/uploads/1778293220506-1000015058.webp",
"sameAs": [
"https://github.com/nguyennhukhanh",
"https://www.linkedin.com/in/nguyennhukhanh"
]
},
"publisher": {
"@id": "https://bytepith.com/#organization"
},
"mainEntityOfPage": {
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#webpage"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://bytepith.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Technology",
"item": "https://bytepith.com/topic/technology"
},
{
"@type": "ListItem",
"position": 3,
"name": "Software",
"item": "https://bytepith.com/topic/technology/software"
},
{
"@type": "ListItem",
"position": 4,
"name": "How Discord's Gateway Handles 12M+ WebSockets",
"item": "https://bytepith.com/article/how-discords-gateway-handles-12m-websockets"
}
]
}
]
}
```