Design a Town-Hall Webinar Platform

Problem statement

Design a town-hall webinar platform that lets one organization host a live session for tens of thousands of employees or registered participants. A small stage — one host, a handful of speakers, possibly a producer switching slides and screen share — broadcasts audio and video to everyone else. The audience does not send media. It watches, reads moderated Q&A, submits questions, upvotes, and votes in polls. After the event, the recording must be available on demand with the same access controls as the live session.

This is the opposite of a video conferencing system. A conference call is symmetric: N participants each send and receive N-1 media streams, and the hard problem is an SFU mesh that keeps everyone's glass-to-glass latency under 300 ms. A town hall is radically asymmetric: a handful of uplink streams must reach 100,000 downlink viewers, and the return channel is text — questions, upvotes, poll votes — not media. The architecture follows that asymmetry. Media distribution is a CDN problem. Interactivity is a fan-out messaging problem. The stage is the only place WebRTC-style low latency matters.

Why the problem is distinctive

Three properties separate this from generic video streaming. First, the audience is bounded and entitled. Unlike a public livestream, everyone watching must be authenticated and authorized — corporate SSO for employees, registration tokens for guests — and the recording inherits that access control for months. Second, the interaction channels carry governance weight. A question shown to 100,000 people passes through moderation; a poll result displayed on stage must be accurate enough that leadership trusts it; both channels become compliance records. Third, the event is scheduled and spiky. Load is not steady. A company all-hands starts at 9:00 sharp: 100,000 players boot within five minutes, a poll opens and receives 80,000 votes inside a minute, and Q&A bursts around each speaker. Capacity must absorb a synchronized thundering herd, not smooth traffic.

Public operating baseline versus design assumptions

Public evidence establishes the category. Microsoft's Teams town hall documentation describes events with up to 100,000 attendees and role-separated stage management. Twitch publicly reports more than 30 million average daily visitors and multi-million concurrent viewership peaks, and its engineering posts describe chat delivered over WebSocket at that scale. YouTube, with more than two billion signed-in monthly users, documents adaptive-bitrate live delivery with both classic and low-latency modes. Zoom reported roughly 300 million daily meeting participants at its April 2020 peak. These are cited public figures for context, not our design targets.

For capacity planning this answer assumes a mature platform: 100,000 concurrent viewers at the largest event, 200,000 registered attendees for it, 3,000 events per month across the platform with 1,500 average viewers, 90-minute average duration, and a three-times burst factor on interactive writes. Every uncited number below is an explicit assumption, target, or budget.

The four architectural planes

1. Media plane: ingest from the stage, transcoding to an ABR ladder, packaging to LL-HLS/CMAF, and CDN delivery to 100,000 players.
2. Interaction plane: WebSocket fan-out for Q&A, chat-lite announcements, poll questions and results, viewer counts.
3. Control plane: event lifecycle, roles and entitlements, scheduling, moderation queues, poll management.
4. Archive plane: recording capture, VOD processing, retention, and on-demand playback under the original entitlements.

A strong answer keeps these planes separate. The CDN must not depend on the control plane to serve a segment. The interaction plane must degrade without taking the video down. The archive plane must not block the live event.