# Design a Live Audio Room App: Clubhouse / Twitter Spaces Source: https://www.techinterview.org/post/3233475101/design-live-audio-room-app/ Updated: 2026-07-26 · techinterview.org Live audio rooms (Clubhouse, Twitter Spaces, [Discord Stage Channels](/post/3233474372/system-design-design-discord-voice-text-channels-server-architecture-webrtc-permissions-bots-real-time-presence/)) are an interesting mobile [system design](/system-design-interview-guides/) topic. They sit between video conferencing (real-time interactivity) and live streaming ([large-scale fanout](/post/3233474168/system-design-twitter-news-feed-timeline-fanout-on-write-fanout-on-read-celebrity-problem-ranking-caching/)). 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.