Design a Massive Webinar with Real-Time Q&A

Problem Statement

Design a webinar platform that lets one to five speakers broadcast audio and video to 10,000–100,000 simultaneous attendees, while supporting real-time Q&A with moderation, live polls, optional text chat, recording for replay, and analytics. The system must handle the fundamental asymmetry between production and consumption: a tiny upstream (1–5 media sources) fans out to a massive downstream audience.

This is not a peer-to-peer video call. In a Zoom meeting with 10 participants, every node both sends and receives. In a massive webinar, the topology is a directed acyclic graph: speakers produce, the platform transcodes and replicates, and attendees consume. Interaction flows back through separate, lower-bandwidth channels (Q&A text, poll votes, chat messages) that have their own latency, moderation, and burst characteristics.

Why This Problem Is Distinctive

A video-on-demand system can pre-process content. A live webinar cannot. The glass-to-glass latency budget is tight (under 5 seconds for broadcast mode, under 500 ms for interactive mode), the fan-out is extreme (one stream becomes 100,000 simultaneous decodes), and the interaction channels must remain responsive even when the media path is under stress.

The Q&A subsystem introduces a second hard problem: content moderation at event speed. A question submitted by attendee #47,832 must pass through spam filters, profanity checks, and human moderator approval before the host sees it—all within 2–5 seconds. During a popular session, hundreds of questions arrive per minute, creating burst loads on the moderation pipeline.

Polls create a third challenge: write amplification. When a host launches a poll, 100,000 attendees may vote within 30 seconds. The vote-ingestion path must absorb a burst of 3,000+ writes per second, aggregate results in real time, and close the poll atomically.

The Three Latency Tiers

1. Interactive tier (< 500 ms): Speaker audio/video to co-panelists. Uses WebRTC or a proprietary real-time protocol.
2. Broadcast tier (2–8 seconds): Speaker content to attendees via low-latency HLS, DASH, or LL-HLS over CDN.
3. Engagement tier (< 1 second for acknowledgements): Q&A submissions, poll votes, chat messages via WebSocket or server-sent events.

A strong answer separates these tiers explicitly. Collapsing them into one protocol choice is the most common interview mistake.

The Four Architectural Planes

1. Media plane: Ingest, transcode, package, distribute, and play audio/video.
2. Engagement plane: Q&A, polls, chat, reactions, and hand-raise signals.
3. Control plane: Event scheduling, registration, role management, recording triggers.
4. Analytics plane: Attendance, engagement scores, poll results, replay views, export.

Each plane has different consistency, latency, and availability requirements. The media plane is loss-tolerant for individual frames but intolerant of multi-second stalls. The engagement plane is message-oriented and must preserve order per attendee. The control plane is strongly consistent. The analytics plane is eventually consistent.

Public Operating Baseline

YouTube Live has served over 95 million concurrent viewers for a single stream. Twitch sustains 35+ million average concurrent viewers daily. Zoom Webinar supports up to 50,000 attendees per session. Microsoft Teams Town Hall handles 20,000 attendees standard, 100,000 with Teams Premium. GoToWebinar supports 3,000 attendees. These are published figures from company sources, not our design targets.

For capacity planning, this answer assumes a mature platform with 500 concurrent live events, 50,000 peak attendees on the largest single event, and 2 million total attendees across all events at platform peak.