Live audio rooms (Clubhouse, Twitter Spaces, Discord Stage Channels) are an interesting mobile system design topic. They sit between video conferencing (real-time interactivity) and live streaming (large-scale fanout). The interview tests whether you understand the tradeoffs and can design at the right scale.
Functional requirements
- Host can start a room with title and topic. Interviewers want to see the full room lifecycle — creation, a room ID, discovery so others can find it, and teardown when the host leaves or the last speaker drops.
- Listeners can join (passive). This is the common case, so make joining a single tap with no negotiation: the app pulls the stream and audio starts playing.
- Listeners can request to speak; host can promote them. The promotion path is where the interesting state changes live — a listener moves from a read-only stream to a bidirectional connection, and the host holds the approval gate.
- Speakers send audio in real time to all listeners. This is the latency-sensitive path; a few speakers talking over each other is fine, and the hard part is delivering their mixed audio to everyone at once.
- Chat / reactions alongside. Text chat and emoji reactions ride a separate channel — usually a websocket — since they don’t need the tight timing that audio does.
- Recording (optional). Call this out as optional early and revisit it later; it changes your storage and consent story but not the core real-time design.
Non-functional
- Sub-300ms latency between speaker and listener
- Scale to thousands of listeners per room
- Reasonable battery for hour-long rooms
- Resilient to speaker network drops
Architecture
Two components:
- Speaker layer: handful of speakers send audio to a media server (SFU). WebRTC for low latency.
- Listener layer: thousands of listeners receive a mixed audio stream from a CDN-fed origin. Higher latency but cheaper at scale.
Why split speaker and listener layers?
WebRTC scales to ~100 peers per room before the SFU becomes the bottleneck. With thousands of listeners, you need different topology.
Implementation:
- Speakers connect to SFU via WebRTC
- SFU mixes speaker audio
- Mixed stream is sent to a transcoding/encoding service
- Encoded stream uploaded to CDN with HLS/DASH
- Listeners pull from CDN — 5–10s latency, scalable to millions
The “raise hand to speak” flow
- Listener taps “raise hand”
- Server notifies host with the request
- Host approves; listener is promoted to speaker
- Listener’s app switches from CDN-pull to WebRTC speaker connection
- Brief audio gap (1–3s) during the transition
Audio capture and processing
- Echo cancellation, noise suppression on capture (platform APIs). Run these on-device before the audio leaves the phone, using the built-in stacks (WebRTC’s AEC, iOS/Android voice processing) rather than rolling your own.
- Voice activity detection — mute speakers automatically when not talking. VAD cuts background noise and saves bandwidth by suppressing a speaker’s stream when they go quiet; interviewers like to hear you gate on it instead of always sending.
- Codec: Opus, 32–64 kbps. Opus is the default for voice because it handles low bitrates well and degrades gracefully under packet loss; naming the bitrate range shows you know voice needs far less than music.
- Mono channel; voice does not benefit from stereo. Downmix to mono to halve the bandwidth — stereo separation adds nothing for a single speaker’s voice.
Moderation
- Host can mute speakers. Mute is a server-enforced state, not a client hint — a muted speaker’s audio is dropped at the SFU even if their app keeps sending.
- Host can remove participants. Removal tears down the offending user’s connection and blocks rejoin for that room, so keep a per-room ban list.
- Listeners can report. Reports feed a moderation queue and should capture a short buffer of recent audio so reviewers have context.
- Recording (with consent) for review. Retain a rolling recording for a limited window so reported incidents can be checked, and make the consent explicit to users when a room is being recorded.
For abuse: real-time AI moderation (transcribe + classify); automatic action on policy violations.
Recording
Server-side recording of the mixed audio stream. Saved to S3 or equivalent. Optionally transcribed for searchable archives.
Battery
- Listeners on CDN-pull have negligible battery cost (just audio playback)
- Speakers running WebRTC are heavier
- Background mode supports listening with screen off
Why did Clubhouse fade?
Engineering was solid; product fit was the issue. Live audio competes with podcasts (asynchronous) and video (visual). Twitter Spaces survives because it integrates with the existing social graph.
Frequently Asked Questions
Why not use WebRTC for everyone?
SFU and TURN costs scale with peer count. WebRTC for 1000 peers in one room is expensive. CDN-pull is far cheaper for the listener layer.
How does the “promote to speaker” feel instant?
Pre-warm the WebRTC connection in the background while the user has hand raised. When promoted, the swap is faster.
Can the same architecture handle live video?
Yes — Twitter Spaces with cameras, Discord Stage with video. Same speaker/listener split with video added.
Keep sharpening your system design:
