How Discord Handles 40 Billion Messages Per Day

You know the fix: longer prompts, more context, clearer constraints. But typing all that takes five minutes per prompt, so you shortcut it. Every time.

Wispr Flow lets you speak your prompts instead of typing them. Talk through your thinking naturally — include context, constraints, examples — and get clean text ready to paste. No filler words. No cleanup.

Works inside ChatGPT, Claude, Cursor, Windsurf, and every other AI tool. System-level, so there's nothing to install per app. Tap and talk.

Millions of users worldwide. Teams at OpenAI, Vercel, and Clay use Flow daily. Free on Mac, Windows, and iPhone.

Try Wispr Flow free

500+ speakers. 18 content tracks. Workshops, masterclasses, and the people actually shipping the tools you use every day. WeAreDevelopers World Congress — September 23–25. Use code GITPUSH26 for 10% off.

Get Your Pass

Discord delivers 40 billion messages every single day to 150 million daily active users. Not emails. Not notifications. Real time chat messages, fanning out to thousands of users per server, with sub second delivery. And they do it with a surprisingly small engineering team using three technologies most companies would never combine: Elixir, Rust, and ScyllaDB.

Most companies pick Java or Go for backend services. Discord picked Elixir, a functional language that runs on the Erlang VM (also called BEAM). That sounds like a hipster choice until you understand what the Erlang VM was built for.

Erlang was created by Ericsson in the 1980s to run telephone switches. Those switches needed to handle millions of simultaneous calls, never crash, and hot swap code without downtime. Sound familiar? That's exactly what a chat platform needs.

When a user connects to Discord, the system spins up a lightweight GenServer process (think of it as a tiny isolated worker that holds state and processes messages one at a time). Each user session gets one. Each Discord server (they call them "guilds") gets one. These aren't OS threads. They're Erlang processes, and the VM can run millions of them simultaneously on a single machine.

Discord hit exactly that wall. Fan out to large guilds was taking 900ms to 2.1 seconds. Sending messages between Erlang processes costs about 30 to 70 microseconds per call. Multiply that by 30,000 recipients, and you've got a problem.

The fix was a library they built called Manifold. Instead of sending a message to every session process individually, Manifold groups recipients by which Erlang node they live on. Then it sends one message per node, and a worker process on that node handles the local fan out.

So if 30,000 users are spread across 20 Erlang nodes, the guild process makes 20 sends instead of 30,000. Each node's worker handles local delivery. That turned a 2 second fan out into something that happens in milliseconds.

Discord runs 400 to 500 Elixir machines to handle their entire chat infrastructure. Five engineers maintain 20+ Elixir services. That's the Erlang VM earning its keep. Fault tolerance is baked in. If a process crashes, only that process restarts. The rest of the system doesn't even notice.

Every Discord client (mobile, desktop, browser) maintains a persistent WebSocket connection to a gateway server. This is the real time pipe. When you see a message appear instantly in a channel, it came through this WebSocket.

The gateway layer is a cluster of Elixir nodes. Each gateway server handles up to 500,000 live sessions. When a user connects, the gateway authenticates them, subscribes them to all their guilds, and starts streaming events.

The API layer runs on Python. Yes, Python. Not everything needs to be Elixir. HTTP request/response doesn't benefit from the Erlang VM the way persistent connections do. Discord picks the right tool for each job, not one tool for everything.

Here's where the story gets really good. In 2017, Discord stored billions of messages on 12 Cassandra nodes. By early 2022, that had grown to 177 nodes. And Cassandra was falling apart.

The problems were classic Cassandra pain:

Hot partitions. Messages are partitioned by channel and time bucket. A viral channel with millions of messages creates a hot partition. All reads and writes for that channel hit the same node, and Cassandra's performance degrades for everyone on that node.

Garbage collection pauses. Cassandra runs on the JVM. The JVM's garbage collector periodically freezes the application to clean up memory. At Discord's scale, these pauses caused latency spikes that rippled across the cluster.

Maintenance nightmares. The team had to perform what they called the "gossip dance," manually pulling nodes out of rotation for compaction and repairs. This was a recurring operational burden that ate engineering time.

ScyllaDB was the answer. It's a Cassandra compatible database written in C++. No JVM, no garbage collection pauses. It uses a shard per core architecture where each CPU core owns its own memory and data. No cross core coordination, no locks, no GC.

That p99 read latency drop from 125ms to 15ms is the number that matters. p99 means 99% of all reads complete within that time. Going from 125ms to 15ms means even your slowest reads are now fast. Users feel this. Messages load instantly instead of having that brief flicker.

Discord didn't just swap databases. They built a new layer between their application code and ScyllaDB using Rust. This data services layer does something clever: request coalescing.

When thousands of users open the same channel at the same time (say, a big announcement drops in a server with 100,000 members), they all request the same message history. Without coalescing, that's 100,000 identical database queries. With coalescing, it's one query. The first request triggers the actual database read. Every subsequent request for the same data subscribes to that in flight query and gets the result when it completes.

Rust was the right choice here because this layer needs to be fast, memory safe, and predictable. No garbage collector. No runtime overhead. Just raw performance where it matters most.

The Rust team also built a custom migration tool that moved trillions of messages from Cassandra to ScyllaDB. The initial plan used Apache Spark and estimated 3 months. The Rust migrator did it in 9 days, hitting peak speeds of 3.2 million messages per second. It used SQLite for local checkpointing so it could resume from exactly where it left off if interrupted.

Discord's stack looks unusual on paper. Elixir for real time. Python for API. Rust for data services. ScyllaDB for storage. Four different technologies, each chosen for a specific job.

But here's what makes it work: clear boundaries. The gateway handles connections and never touches business logic. The API handles business logic and never manages connections. The data services layer handles database access and never handles user facing logic. Each layer can be scaled, deployed, and debugged independently.

This isn't accidental. It's the result of years of hitting walls and choosing targeted rewrites over full platform migrations. They didn't rewrite everything in Rust. They identified the one layer where Rust's zero cost abstractions mattered (the database access layer) and rewrote only that.

Follow me on Youtube · LinkedIn · X · Instagram to stay updated.

See you in the next one!
Scortier, Signing Off!