Discord Rust database rewrite is the headline everyone repeats, and it's wrong: two unrelated engineering fixes got fused into one myth. Here's the real chain of decisions nobody untangles.
Start with Read States, a small Go service tracking what channels and messages you've already read. Its in-memory cache worked fine until eviction: Go's garbage collector reclaimed freed memory on its own schedule, causing latency spikes roughly every two minutes. This is the actual discord read states rust story: engineers rewrote the service in Rust, keeping the identical cache design and eviction logic. The only change was ownership, Rust frees memory the instant an entry is evicted, no collector, no scheduled pause. Spikes gone.
That fixed one small service. The bigger problem was messages, trillions of them, all passing through Discord's monolith into a new Rust intermediary layer called data services. Requests route by a consistent-hash key (the channel id), so every request for one channel always lands on the same instance, building a warm cache the way a mail clerk memorizes one route. When a channel goes viral, request coalescing collapses thousands of duplicate queries into a single in-flight worker task, every caller subscribes to that one read instead of hammering the database separately.
That one read still had to land on Cassandra, and a single hot partition could take a whole node down. This is where the discord cassandra to scylladb migration comes in: ScyllaDB's shard-per-core design gives every core its own independent partition instead of one shared node, so a hot partition burns one core and never spreads to starve the rest.
Moving trillions of existing messages off Cassandra, in production since 2017, with the standard open-source migrator was estimated at roughly three months, node by node. So the team built their own migrator in Rust in about a day: it reads token ranges directly out of Cassandra, writes concurrently into ScyllaDB, and checkpoints progress to a local SQLite file so a crash resumes from the last checkpoint instead of starting over.
Three separate fixes, three separate reasons. Watch to see exactly why did Discord rewrite in Rust, and which decision actually made the other two survivable.
TIMESTAMPS:
0:00 THE RUST MYTH
0:15 177 NODES. PAGES AT 2AM.
0:54 READ STATES: GO, 2020
1:18 RUST: NO GC PAUSE
2:03 ENTER: DATA SERVICES
2:29 SAME CHANNEL, SAME WORKER
2:55 ONE READ, MANY CALLERS
3:40 SHARD-PER-CORE = NO SPREAD
4:06 3 MONTHS, STANDARD TOOLING
4:33 3 MONTHS - 9 DAYS
5:06 177-72 NODES, 125MS-15MS
5:32 TWO FIXES, ONE MYTH
6:09 THE MODEL NEVER CHANGED
7:00 THE SHAPE OUTLIVED THE REWRITE
Sources are linked below.
CONNECT:
Subscribe: / @getexplodedview
ABOUT THIS CHANNEL:
Animated deep-dives into how real software systems work. Narration is synthesized; scripts are researched, cited, and human-reviewed.
#DiscordEngineering #ScyllaDB #RustLang #Cassandra #SystemDesign