That was Discord’s selling point when it launched back in 2015. It was chat made for gamers who were sick of paying for TeamSpeak and sick of Skype eating their CPU.
That pitch worked for a lot more people than just gamers. Now, your company or community might use Discord for coordination, running customer support, or just hanging out in a voice channel while everyone works in silence. To support this, the feature set now includes threads, forums, stage channels, app integrations, and a full developer platform.
If you're building something like it, you're signing up for nearly every hard problem in real-time software. This guide walks through each layer of that stack to help you pick the right tools, avoid the wrong ones, and ship something people actually want to talk in.
Should I Use a Managed Chat SDK or Build Messaging From Scratch?
A managed SDK provides channels, threads, reactions, typing indicators, presence, moderation, and prebuilt UI components out of the box.
Here's how the main options compare:
| SDK | Starting Price | Scale | React Native SDK | Flutter SDK | Standout Feature |
|---|---|---|---|---|---|
| Stream Chat | Free (Maker: 2K MAU), $399/mo (10K MAU) | 1B+ end users | Yes (pre-built UI kit) | Yes (pre-built UI kit) | Channels, threads, and video API under one vendor |
| Sendbird | $399/mo | 300M+ users | Yes | Yes | Mature moderation and analytics |
| CometChat | $109/mo | Mid-scale | Yes | Yes | Voice/video bundled with chat |
| PubNub | $49/mo (1K MAU) | Enterprise | No dedicated kit | No dedicated kit | 99.999% SLA |
| Ably Chat | Usage-based | 1B+ devices (infra) | Via Ably core SDK | Via Ably core SDK | New in 2025, built on proven pub/sub infra |
Stream Chat is the closest to Discord-level feature parity among managed SDKs. You get:
- Custom channel types (text, voice lobby, announcements, or your own)
- Threaded replies
- @mentions
- File attachments
- Read state
- AI-powered moderation
The React Native and Flutter UI kits handle message list virtualization, image previews, and link unfurling, which saves significant frontend development time. Stream also offers a Video API so that you can handle both chat and voice/video calls from a single vendor with unified SDKs and a single dashboard.
What’s the Best WebSocket Framework for Building Real-Time Messaging?
If you're building from scratch, you're choosing a WebSocket framework and building persistence, presence, threading, and reactions yourself.
- Phoenix Channels (Elixir) is the gold standard for real-time messaging infrastructure. Discord validated this choice at scale, running 12 million concurrent users across 20+ Elixir services. Phoenix's built-in Presence module uses CRDTs to track online/offline state across distributed nodes without external dependencies. The trade-off is a smaller pool of Elixir developers to hire.
- Socket.IO remains the most accessible option for Node.js teams. Rooms map naturally to Discord-style channels, and the Redis adapter enables horizontal scaling. The downside: you build everything above the transport layer yourself, including message persistence, threading, typing indicators, and reactions.
- Centrifugo is a standalone real-time messaging server written in Go that handles 1 million WebSocket connections and delivers 30 million messages per minute on a single node. This is the best option if you want a dedicated real-time layer that's language-agnostic.
For most teams, the practical choice comes down to using a managed chat SDK like Stream Chat if you want to ship in weeks, or building on Phoenix Channels if you need full architectural control and plan to operate at significant scale.
What Should I Use for Voice and Video Calls?
The voice/video decision mirrors the chat decision: managed service for speed, or open-source for control. The two strongest options map cleanly to those paths.
Stream Video is the best managed option, especially if you're already using Stream Chat. You get a unified SDK surface for both chat and calling, a single dashboard for analytics and moderation, and consistent UI components across React Native and Flutter. Dynascale handles automatic quality optimization based on network conditions. The key advantage for a Discord-like app is reducing vendor complexity: one integration, one billing relationship, one set of SDKs to maintain for both chat and voice/video.
LiveKit is the strongest open-source option. It's a fully open-source SFU with an optional managed cloud, and zero code changes to switch between them. LiveKit's SFU supports up to 100K simultaneous participants per session with track-level subscription control, which maps well to Discord's many-listeners/few-speakers voice channel model. It ships SDKs for 11 platforms, plus built-in recording, screen sharing, end-to-end encryption, and simulcast.
Other options worth knowing about:
- Agora: The most mature global infrastructure via its SD-RTN network. Fully proprietary, but excellent React Native and Flutter UI kits.
- 100ms: Founded by ex-Meta engineers. Single SDK covers conferencing and live streaming. Caps at 200 interactive participants per room.
- mediasoup: Highest raw SFU performance (C++ core), but no mobile SDKs, no official support, and no cloud option. Only for teams with deep WebRTC expertise.
One note on Twilio Video: Twilio originally announced an end-of-life for December 2024, then extended it to December 2026, and then reversed the decision entirely in October 2024. Video will remain a standalone product, but the whiplash makes it a risky foundation for a new project.
What Backend Language and Framework Should I Use?
Discord's own backend is polyglot: Elixir/Phoenix for the WebSocket gateway, Python (FastAPI) for the API, and Rust for high-throughput data services between the API and database layers. This approach, using each language where it's strongest, is worth emulating.
For most teams, here's how to think about backend language choice:
- Node.js with NestJS gets you to an MVP fastest. TypeScript end-to-end (shared types with your React Native frontend), the largest hiring pool, and NestJS's modular WebSocket Gateways with Socket.IO or raw WS support. Performance is strong for I/O-heavy workloads. The limitation is single-threaded execution: scaling to high connection counts requires clustering and Redis pub/sub for cross-node communication.
- Go excels for infrastructure-layer services. Centrifugo proves Go can handle Discord-level connection counts through goroutine concurrency. If you're building custom real-time infrastructure (rather than using a managed SDK), Go is the strongest choice for connection management and message routing.
- Elixir/Phoenix is purpose-built for the problem. The BEAM VM's lightweight process model, built-in distributed clustering, and Phoenix Channels/Presence make it the most natural fit for a Discord-like system. The trade-off is ecosystem size and hiring.
- Rust delivers the best raw throughput and lowest memory usage. Discord uses it as a data service layer. Consider Rust for performance-critical paths, such as message fanout and search indexing, not necessarily for your entire backend.
A practical starting architecture: NestJS for the API and business logic, with Centrifugo or a managed SDK handling real-time delivery. Add Rust services for specific hot paths as you scale.
What Database Architecture Does a Discord-Like App Need?
No single database handles all the workloads in a Discord-like app. You need a tiered approach.
Message storage is the hardest problem at scale. Discord migrated from MongoDB to Cassandra, then to ScyllaDB, over seven years. For teams not yet at the trillion-message scale, Postgres handles messages, users, channels, and permissions in a single database. Use time-based table partitioning for messages (partition by month or week) and Postgres' LISTEN/NOTIFY for lightweight real-time change signaling. This approach scales comfortably into the tens of millions of messages.
Ephemeral data (presence, typing indicators, session state, cross-node pub/sub) needs an in-memory store. Valkey is the recommended choice after Redis's 2024 license change to AGPL. It's a Linux Foundation project with BSD-3 licensing. Dragonfly claims 25x Redis performance with a multi-threaded C++ architecture but uses a BSL license.
Search requires its own engine once you outgrow Postgres’ full-text search. Meilisearch (Rust, sub-50ms queries, hybrid AI/keyword search) is the easiest to operate for small to mid-scale. Typesense (C++, Raft-based clustering) handles production scale better. Elasticsearch is necessary only at the billions-of-messages scale.
A practical progression:
- MVP through \~1M users: PostgreSQL + Valkey. One database, one cache.
- Growth stage: Add ScyllaDB for message storage, keep PostgreSQL for relational data, add Meilisearch or Typesense for search.
- Hyperscale: ScyllaDB for messages, PostgreSQL for metadata, Elasticsearch for search, Rust data services for hot paths.
How Should I Handle Auth and Permissions?
Authentication and authorization are separate concerns in a Discord-like app. Auth handles identity (who is this user?), while permissions handle access control (can this user send messages in this channel?).
For authentication, three services cover the spectrum:
- Clerk: Best developer experience. Pre-built React components, organization structures that map to Discord-style servers, and session management out of the box.
- Supabase Auth: Best value when bundled with Supabase's database and storage. Row-level security policies integrate directly with your PostgreSQL data model.
- Auth0: Enterprise-grade with SSO, HIPAA compliance, and advanced MFA options. More complex to configure.
For permissions, Discord uses a bitfield-based system where each permission (Send Messages, Manage Channels, Kick Members) is a bit flag, and roles combine using bitwise operations. This is compact and fast to evaluate. You can implement this pattern directly, or use a tool like RBAC/ABAC engine Apache Casbin.
What Stack Should You Pick?
The answer depends on whether you're optimizing for time-to-market or long-term infrastructure control.
For most teams, the fastest path to a production Discord-like app is a managed core: Stream for chat and video, Supabase for auth and your relational database, React Native for mobile, and Nest for web. This gets you real-time messaging, voice/video, and cross-platform UI in weeks. You skip the hardest infrastructure problems entirely and focus on what makes your app different from Discord, which is presumably the reason you're building it.
The smartest approach is to start managed and graduate selectively. Ship with Stream and Supabase, learn where your bottlenecks actually are, and replace components with self-hosted alternatives only when you have concrete evidence that you need to. Every successful chat platform, Discord included, started simpler than it is today.