Skip to content
Search

Discord

lastmod 2025-05-06created 2021-11-0520 edits

Your Place to Talk and Hang Out

Categories ite

Discord Developer Portal

Discord_Developer_Portal_-Application-_Menu.jpg

General Information

What should we call your creation? What amazing things does it do? What icon should represent it across Discord? Tell us here!

Installation

Choose how users install your app. Create an install link, choose which authorization methods to support, and define the scopes and permissions you want to request.

OAuth2

Use Discord as an authorization system or use our API on behalf of your users. Add a redirect URI, pick your scopes, roll a D20 for good luck, and go!

Bot

Bring your app to life on Discord with a bot user. Join chats and interact directly in users' servers.

Rich Presence Art Assets

Integrate your game tightly with Discord and let players share the game by joining directly from the client.

Application Testers

You can invite up to 50 Discord users to test your application. They must have a registered email and a positive attitude. ^)

Monetization

-

Activities

-

Installation

Authorization Methods
Choose the authorization methods your app supports. Apps can be installed to both users and guilds.
You can choose between the "User Install" and "Guild Install" methods.
Install Link
Use the provided install link or register a custom link. If you choose a custom link, users adding your app will be redirected to your URL instead of Discord's add-app flow.
You can choose one of "None", "Discord Provided Link", or "Custom URL"
Default Install Settings
Choose the default set of scopes and permissions your app will request.

Bot

Build-A-Bot
Bring your app to life by adding a bot user. This action is irreversible (because robots are too cool to destroy).
Token
For security purposes, tokens can only be viewed once, when created. If you forgot or lost access to your token, please regenerate a new one.
  • The Access Token needed for development can be generated here.
Authorization Flow
These settings control how OAuth2 authorization is restricted for your bot (who can add it and how).
Public Bot
Public bots can be added by anyone. When unchecked, only you can join this bot to servers. -> No/Yes
Requires OAuth2 Code Grant
If your application requires multiple scopes, you may need the full OAuth2 flow so the bot doesn't join before your application is granted a token. -> No/Yes
Privileged Gateway Intents
Some #Gateway Intents require approval if your bot is verified. If your bot is not verified, you can toggle those intents below to access them.
Presence Intent
Required for your bot to receive presence update events. -> No/Yes
Server Members Intent
Required for your bot to receive events listed under GUILD_MEMBERS. -> No/Yes
Message Content Intent
Required for your bot to receive message content in most messages. -> No/Yes

INFORMATION

Once your bot reaches 100 or more servers, verification and approval are required. Read more here

Bot Permissions
Need help with bit math? Use the tool below to calculate your bot's permissions integer based on the features it needs.
  • Select the permissions you need from the list, and it tells you the Integer for those Permissions computed Bitwise.

Gateway Intent

Maintaining a stateful application can be difficult, especially at scale, given the amount of data an app is expected to handle over a Gateway connection. Gateway intents are a system that helps reduce the computational burden.

Performance Optimization

Why Discord is switching from Go to Rust

With only the most basic optimizations, the Rust version outperformed the heavily hand-tuned Go version

  • Discord's "Read States" service: keeps track of which channels and messages have been read.
    • However, Go's memory model and GC caused latency spikes
  • Rust's memory management and lack of GC were a good fit for this
  • Early on, it didn't support an asynchronous model, but the latest version includes it.
  • Now Rust is used in many places, including the game SDK, video capture and encoding, and backend services

How Discord minimized network disk latency

  • How Discord minimized network disk latency | GeekNews (Google Cloud Platform, Persistent Disk latency, etc ...)
  • Runs a NoSQL DB cluster (ScyllaDB) that handles 2 million messages per second
  • The biggest factor in DB performance is the latency of the physical disk hardware
    • At low query volumes it doesn't matter, but beyond a certain point, even a 1–2ms read time causes a queue of disk reads to build up, and the queries themselves time out
  • Disk latency is usually in microseconds, so why do disk operations take 1–2ms?
  • Discord runs most of its hardware on Google Cloud
    • Google Cloud supports NVMe-based local SSDs, but Discord's own tests found reliability issues, so they weren't comfortable using them as critical data storage
    • Persistent Disk can be attached/detached from servers in real time, resized without downtime, snapshotted at any time, and is designed to be replicated by default
      • The problem is that it isn't attached directly to the server but connected over the network
  • No matter how low the local network connection latency is, it isn't lower than PCI/SATA
    • Network: 1–2ms; directly attached disk: 0.5ms
  • Like an HDD, a local SSD loses the data on that disk if a hardware problem occurs, and if the host itself has a problem, snapshots are impossible too, so the data can be lost entirely
    • So Discord doesn't use Local SSD and uses Persistent Disk instead

Problem analysis

  • A storage device combining only the advantages of local SSD and Persistent Disk would be ideal, but no such thing exists. What if we take only some of the advantages?
  • For Discord, write latency is not a problem. What affects performance is "read latency"
  • "Disk resizing without downtime" is not an essential feature. The size can be predicted in advance
  • The final requirements were
    • Stay on GCP
    • Use Point-in-Time snapshots for data backups
    • Make minimizing read latency the top priority
    • Don't sacrifice existing database uptime guarantees
  • It seemed good to use GCP's Local SSD for reads and write to Persistent Disk
    • Could such a Super-disk be built at the software level?

Building the Super-Disk

  • The requirement was basically a Write-Through cache. Use GCP's local SSD as the cache and PD as the storage layer
  • Since the DB servers run Ubunut, disk-level caching can be applied at the Linux kernel level (modules such as dm-cache, lvm-cache, bcache)
  • However, experiments showed that when a bad sector occurs on the cache disk, the entire read operation fails
    • When a bad sector occurs, the data should be read from the storage layer and overwritten, but none of the disk caching solutions evaluated had this feature
    • When a bad sector occurred, the database shut down due to data integrity concerns
  • An additional requirement was added: "must survive bad sectors on the local SSD"
  • So they looked into the Linux kernel's "md"
    • md supports creating software RAID
    • Mirroring the SSD and PD doesn't solve the problem, because more than half of the reads would come from the PD
    • md has "write-mostly", which traditional RAID doesn't have
      • If a particular disk is marked write-mostly, it is excluded from normal reads, and reads go to it only when there is no other option. "Useful for devices connected over a slow link"
      • In other words, combining the SSD and PD as RAID1 and setting the PD to write-mostly meets the requirements
  • The last remaining problem was that GCP's Local SSD is exactly 375GB in size
  • For some applications, Discord needs more than 1TB per DB instance
  • So they decided to combine multiple SSDs as RAID0
  • The final setup is
    • md0: 4 local SSDs combined as RAID0
    • md1: md0 and the Persistent Disk combined as RAID1

DB performance

  • The results were exactly as expected
  • Even at peak, disk operations don't pile up in the queue, and query latency doesn't change
  • Performance improved, so each server can handle more queries
  • People who have used RAID may doubt whether this "just works", but in reality many things happened, and the rest will be covered in detail separately

Why Discord switched from Cassandra to ScyllaDB + Rust

However, as its user base grew, Discord faced the difficult challenge of handling trillions of messages efficiently. Its existing database system, Cassandra, suffered from slowdowns and performance degradation due to hot partitions.

  • As Discord grew, it kept replacing its message storage DB
  • Initially a single MongoDB. In November 2015, as the message count grew to 100 million, MongoDB's limits became apparent
  • In 2017, it switched to a 12-node Cassandra cluster to store billions of messages
  • In 2022, as messages surged into the trillions, the infrastructure grew massively to 177 nodes, latency became unpredictable, and maintenance costs became extremely high
  • Discord's problem with Cassandra was Hot Partitions. Specific parts of the DB became overloaded, degrading the performance of the entire application
    • Because Cassandra's internal data structure uses LSM trees, reads are more expensive than writes, and concurrent reads by many users on a single server create hotspots and lead to performance degradation
    • Maintenance tasks such as SSTable compaction affected overall performance and compounded the problem
  • So they began redesigning the architecture by integrating various components
    • Using a monolithic API, data services implemented in Rust, and a storage system based on ScyllaDB (a Cassandra-compatible DB developed in C++), etc.
  • Adopting ScyllaDB brought significant improvements
    • p99 read latency dropped to 15ms, compared to Cassandra's 40–125ms
    • p99 write latency dropped to 5ms, compared to Cassandra's 5–70ms
  • Discord engineers wrote the data services in Rust
    • Used Rust's Feareless Concurrency to control concurrent traffic to hot partitions
    • Rust's libraries and concurrency features were a great fit for Discord's requirements
    • The data services act as an intermediary between the API monolith and the database clusters

How Discord reduced WebSocket traffic by 40%

  • When a client connects to Discord, it receives real-time updates about what's happening through a service called the "gateway"
  • Since late 2017, clients' gateway connections have been compressed with zlib, making messages 2 to 10 times smaller
  • Zstandard (zstd) has a higher compression ratio and shorter compression time than zlib, and supports dictionaries to reduce bandwidth further
  • Zstd test results in 2019 weren't very positive, but they decided it was worth trying again

Zstd streaming

  • Zlib used streaming compression, while zstd did not
  • On small payloads, zstd performed worse than zlib
  • They forked ezstd, the zstd binding for Elixir, and added streaming
  • Switching to zstd streaming brought large improvements in compression ratio and speed over zlib streaming
  • Optimization tuning - adjusted zstd compression parameters such as Chainlog, hashlog, and windowlog to balance memory usage and compression time

How Discord indexes trillions of messages

  • How Discord indexes trillions of messages | GeekNews
  • To overcome the limits of its existing Elasticsearch-based search infrastructure, Discord redesigned the whole architecture on Kubernetes, dramatically improving message indexing performance and reliability
  • The existing Redis queue risked losing messages, but it was replaced with PubSub to guarantee reliable message delivery, while messages are sorted by cluster/index for efficient processing
  • Introduced a "cell" architecture that distributes across many small Elasticsearch clusters, solving node overload and the inability to update
  • Personal DM messages and server (guild) messages are indexed in separate cells, which became the basis for the newly introduced DM-wide search feature
  • Very large communities (BFGs) can scale beyond Lucene's maximum message count limit through dedicated cells and multi-shard indexes

See also

  • Wildbeast - multipurpose Discord bot framework
  • Overpass - self-hosted streaming platform
  • Revolt - open-source alternative to Discord
  • Slack
  • Devzat - SSH chat server for developers

Favorite site

author Zer0 sitemap