Design Clubhouse

Problem statement

Design a live, audio-only social network where users drop in to ephemeral rooms, listen to a stage of speakers, raise a hand to speak, and are promoted or muted by hosts and moderators. The product must create and discover rooms, manage roles (listener, speaker, moderator, host), enforce invite-only or open access, stream multi-speaker audio with conversational latency, survive mobile network churn, and vanish without a permanent audio log unless a safety policy says otherwise.

The defining constraint is latency class. A feed product tolerates seconds; a live audio product must feel like one conversation. Glass-to-glass audio above roughly 400 ms destroys turn-taking, so the media path is a real-time transport problem (UDP, SRTP, Opus, jitter buffers, SFU fan-out), while everything else—room discovery, follows, invites, clubs, notifications, analytics—is an ordinary distributed social backend. A strong answer keeps these two planes separate: the media plane optimizes latency and packet recovery; the control plane optimizes correctness, custody of room state, and durability of social data.

Why this is distinctive

Three properties separate this from designing a messaging or feed system. First, fan-out is asymmetric and hot-tailed: a room may have 3 speakers and 100,000 listeners, and one celebrity room can concentrate a meaningful fraction of the concurrent population. Second, room state is small but authoritative and contested: who is on stage, whose hand is raised, who is muted—these mutate concurrently from phones, must propagate in under a second, and must never double-promote a speaker. Third, ephemerality is a product and legal property: by default no audio is stored, yet safety investigations, moderation appeals, and some jurisdictions require a narrowly scoped, auditable exception path.

Public operating baseline versus design assumptions

Public evidence shows the category is real. Clubhouse reached roughly 10 million registered users by February 2021 on an invite-only model and ran on Agora's software-defined real-time network; Agora publicly claims sub-400 ms global latency and 99.99% availability for its SD-RTN. Discord operates voice for well over 100 million monthly users with a WebRTC-based SFU fleet and, in 2024, published the DAVE protocol for end-to-end encrypted voice and video using Messaging Layer Security. Twitter shipped Spaces in 2021 with host-plus-speakers stage semantics and unlimited listeners. These are cited, company-reported figures used for context only.

For capacity planning this answer explicitly assumes a mature platform: 20 million registered users, 5 million MAU, 600,000 peak concurrent participants, 60,000 concurrent rooms, heavy-tailed audience sizes with a 200,000-listener tail room, and 4 publishing speakers per average room. Unless a number is tied to a citation, it is a stated design assumption, target, or budget—not a claim about any company's private architecture.

The four architectural planes

1. Media plane: edge SFU cascades, Opus encoding, RTP/SRTP transport, jitter buffers, FEC, NAT traversal, active-speaker forwarding, and mix fallback for mega rooms.
2. Real-time control plane: authoritative room state (roles, hand-raise queue, mute flags), presence, signaling over WebSocket, and moderation actions with ordering guarantees.
3. Social plane: profiles, follows, clubs, invites, discovery, notifications, and the durable graph.
4. Trust and lifecycle plane: identity, room tokens, anti-eavesdropping controls, ephemeral data purges, safety-review recording exceptions, and compliance holds.

A strong interview answer states in the first two minutes that audio is a UDP real-time problem solved at the edge, room state is a small strongly consistent aggregate, and everything else can be eventually consistent.