Design a Celebrity Live Interaction Platform

Problem statement

Design a platform where a celebrity or influencer broadcasts live audio/video from their device to a very large fan audience, while fans post questions in a real-time chat, upvote the questions they want answered, and pay tokens for privileged interactions such as pinned shout-outs, highlighted messages, or a scarce one-on-one guest call slot. Sessions may be ephemeral or recorded for replay.

This is not a generic video-on-demand system. It combines three hard, coupled problems. First, one-to-many media distribution at broadcast scale: one upstream encoder must reach hundreds of thousands of concurrent viewers with a glass-to-glass latency low enough that the conversation feels live. Second, a real-time interaction layer: a chat and Q&A stream whose write rate spikes violently when a major celebrity goes live, and whose upvote counts must stay consistent enough to be credible. Third, monetization and safety: every paid message is a financial transaction that must be exactly-once and auditable, and every user-generated message passes through a trust-and-safety pipeline that must not become the latency bottleneck.

Why this is distinctive

A streaming service can buffer; a live interaction cannot. If a viewer's paid shout-out arrives thirty seconds late, the moment is gone and the fan feels cheated, which is a refund and trust problem, not merely a quality problem. If moderation is synchronous and slow, chat stalls. If moderation is skipped, harmful content reaches millions in seconds. The design therefore separates three planes that must never be confused.

The media plane carries the audio/video frames and is optimized for throughput and latency with adaptive bitrate and CDN fan-out. The interaction plane carries chat, Q&A, upvotes, and presence and is optimized for write fan-in and read fan-out. The commerce-and-safety plane carries token purchases, paid-message grants, and moderation decisions and is optimized for correctness, auditability, and policy enforcement. A strong answer keeps these planes decoupled so that a chat spike cannot stall the video, a payment cannot be double-charged, and a moderation backlog cannot block the stream.

Public operating baseline versus design assumptions

Public evidence shows this category operates at enormous scale. Twitch has publicly reported millions of concurrent viewers and millions of unique monthly broadcasters, and its engineering blog describes chat systems that absorb bursts of hundreds of thousands of messages per second during major events. YouTube has described low-latency live streaming built on DASH/HLS with latency targets in the low single-digit seconds. Mux and Agora publish reference architectures for programmatic and interactive live video respectively. These are cited industry figures for context, not requirements for our fictional system.

For capacity planning this answer explicitly assumes a mature platform with 100 million registered fans, 20 million daily active viewers, up to 300 concurrent live sessions, and a single mega-celebrity session peaking at 500,000 concurrent viewers with a chat write rate of 50,000 messages per second. Unless a number is tied to a named company, it is a stated design assumption, target, or budget.

The three architectural planes

1. Media plane: ingest from the celebrity device, transcode into an adaptive-bitrate ladder, distribute through a CDN, and play back with low-latency HLS/DASH or WebRTC for ultra-low-latency tiers.
2. Interaction plane: WebSocket chat gateway, fan-out brokers, presence tracking, Q&A upvote aggregation, and highlight features.
3. Commerce-and-safety plane: token ledger, payment gateway, idempotent paid-message grants, moderation pipeline from cheap synchronous filters to async ML classifiers to human review, and enforcement actions.

A strong interview answer keeps these planes separate. It allows the interaction plane to degrade without breaking media delivery, and it lets the commerce plane enforce correctness without adding latency to playback.