Design a Live Concert Streaming Service

Problem statement

Design a live concert streaming platform where fans buy a ticket or receive an invite, then watch a scheduled concert in real time with minimal buffering, optionally switch camera angles, and participate in live chat, emoji reactions, and tipping. The show starts at a published time, ends a couple of hours later, and may remain available as a bounded replay.

This workload is distinct from both VOD and always-on UGC live streaming. A VOD catalog spreads demand across millions of titles and tolerates pre-warming over days. UGC live platforms spread risk across hundreds of thousands of small channels. A ticketed concert concentrates demand: one asset, one hard start time, a global audience arriving within minutes, and a revenue promise attached to every second of playback. If the catalog page is slow, a user retries. If the concert start fails, the moment is gone and refunds begin.

Why the problem is distinctive

Four properties dominate the architecture. First, the traffic curve is a wall, not a ramp: hundreds of thousands of players authenticate and request the first segment within a few minutes of doors-open, and the same audience leaves at once. Second, access is entitlement-gated: every playback session must be checked against a paid ticket, a promo code, or an invite, with geo and rights restrictions layered on top. Third, the content is ephemeral and rights-sensitive: the performance window is licensed, the recordings need protection against restreaming, and takedown obligations are real. Fourth, engagement is synchronous: chat, reactions, and tips only matter while they are fresh, so the engagement plane has its own latency and fan-out budget that must not interfere with video continuity.

Public operating baseline versus design assumptions

Public evidence establishes that the category operates at serious scale. Twitch reports an average of roughly 31 million daily viewers and millions of concurrent live channels; its chat system has historically absorbed bursts such as community events generating over one hundred thousand inputs per minute. Hybe's 2020 online concert for BTS reported a peak of approximately 756,600 concurrent paying viewers. Esports Charts reported roughly 6.4 million peak concurrent viewers across platforms for the 2023 League of Legends World Championship final. Tomorrowland's 2020 paid digital festival reportedly sold about one million tickets over a weekend. These are cited public figures used as context, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a headline concert with 2 million tickets sold, 1.5 million peak concurrent viewers, 5 million unique viewers across the live window and replay, and a 5x engagement spike during signature moments. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

1. Media plane: venue ingest, redundancy, transcoding, low-latency packaging, origin shielding, CDN delivery, and player behavior.
2. Entitlement and commerce plane: events, tickets, payments, playback grants, DRM licenses, geo policy, and refunds.
3. Engagement plane: chat rooms, reactions, tips, moderation, and creator settlement.
4. Reliability and operations plane: QoE telemetry, incident response, multi-CDN steering, cost control, and evidence.

A strong interview answer keeps these planes separate. Video continuity must survive chat overload, a payment-provider outage must not interrupt playback for ticket holders, and a moderation backlog must never pause the stream.