Design Twitter Spaces

Problem statement

Design Twitter Spaces, a live audio conversation product embedded in the Twitter app. A host creates an ephemeral audio room, invites co-hosts and speakers, and broadcasts their voice to an audience that can range from a handful of friends to hundreds of thousands of listeners. Listeners join, listen in near real time, react with emoji, and may raise their hand to be promoted to speaker. Spaces appear in the home feed so users can discover and join live conversations. By default the audio is ephemeral — nothing is stored unless the host opts into recording.

This is not a tweet, a notification, or a REST CRUD problem. It is a real-time media problem bolted onto a social graph problem. The moment a second person speaks, the system must move continuous audio packets between devices with a few hundred milliseconds of end-to-end latency, while simultaneously rendering a live participant list, hand-raise queue, reactions, and a feed card — all for an audience whose size is unbounded and unknown in advance.

Why the problem is distinctive

A tweet is a durable, eventually consistent document. A Space is the opposite: it is a live, stateful, latency-sensitive session that exists only while people are in it. The two hardest properties are:

1. Bounded latency with unbounded audience. A WebRTC mesh works for 3 people and collapses at 30. Twitter Spaces must serve a room with 11 active speakers and up to hundreds of thousands of simultaneous listeners. Audio fan-out is the dominant cost and the dominant scaling problem.
2. Ephemeral by default, yet fully observable. The product promises that conversations vanish, but trust and safety demands that abuse can be investigated. This forces a careful split: media is not stored, yet session metadata, moderation events, and (when enabled) transcripts are.

The four architectural planes

A strong answer keeps four planes separate so that a failure in one does not cascade into the others:

1. Media plane — the WebRTC Selective Forwarding Unit (SFU) cluster that carries Opus audio between speakers and listeners. It is regional, UDP-based, and latency-critical.
2. Signaling plane — WebSocket servers that manage join/leave, mute, hand-raise, speaker promotion, and room control. It is the coordination layer and must stay correct under churn.
3. Social plane — the Space metadata service, discovery/feed integration, presence, notifications, and the social graph that decides who sees a Space card.
4. Trust & learning plane — moderation, reporting, optional transcription (ASR), recording, audit evidence, and analytics.

The media plane must never block on the social plane. A Space must keep carrying audio even if discovery, transcription, or the follower graph is degraded. Conversely, the social plane must never be coupled to media internals — feed ranking needs room metadata and participant counts, not RTP packets.

Public operating baseline versus design assumptions

Public evidence establishes that the category is real and large. Twitter launched Spaces to all iOS users in May 2021 after a limited beta, and reported that the product was built on WebRTC. Clubhouse, the product that sparked the category, ran on Agora's global software-defined real-time network (SD-RTN) and disclosed sub-400 ms latency at millions of concurrent users; Agora's network spans 200+ data centers. Discord runs voice for tens of millions of daily users through regional voice servers and has published engineering work on scaling voice with WebRTC and selective routing. These are cited company figures used as context.

For capacity planning, this answer explicitly assumes a mature product with 50 million daily active users who might use Spaces, 10,000 concurrent live Spaces at peak, 2 million concurrent participants, and a 5x event peak for high-profile conversations. Unless a number is tied to a citation, it is a stated design assumption, target, or budget — not a claim about Twitter's private architecture.

The single sentence

Build a platform where a regional WebRTC SFU cluster carries live audio, a WebSocket signaling layer coordinates room state, and a durable social layer handles creation, discovery, presence, and trust — with the invariant that audio keeps flowing even when everything else degrades, and nothing is stored unless explicitly enabled.