Streaming to Thousands: Architecting Massive-Scale Live Video Events

In an earlier post we argued that "video call" can mean a lot more than a meeting once it becomes part of a real business process. Here's a case that pushes that idea further still: a platform where the video-call part barely matters, and the real engineering problem is distribution at scale.

The shape of the problem

Some live events (webinars, product launches, town halls, live shows) have a small number of active presenters, actually speaking and on camera, and a much larger audience watching and participating through chat; the same basic shape as a Twitch or YouTube Live stream, running on a custom web interface built specifically for one client (we didn't build that front-end ourselves, so it's not what this post is about).

The audience size for an event like this is genuinely unpredictable. A small session might draw a dozen viewers; a well-promoted one might draw thousands. And every event is time-bounded: intense for an hour or two, then nothing until the next one.

Latency vs. cost: the real trade-off

When presenting to a large audience, there are two real options.

1. Full real-time. Several companies already offer massive-scale WebRTC, video calls with thousands of participants, or media servers to build a custom application on top of. It's genuinely real-time, but it means running one live session per viewer. (Talk to us if that's the trade-off your case needs.)
2. HLS distribution. The stream reaches an edge cache once, and viewers pull from it instead of each holding a session with the origin. It trades away some latency (typically a few seconds to around thirty), but for most massive-scale distribution it's the better cost/efficiency choice, and it's what webinar tools, Twitch, and YouTube Live actually use, and what we used too, for this specific case.

How the pieces actually fit together

The mechanism underneath is, on its own, fairly simple: the presenters run a small, ordinary WebRTC video call among themselves. A silent observer, the same "invisible participant" idea we've written about before, joins that call to capture its composed output, which then gets chunked in near-real-time for HLS distribution to everyone else.

That part is the basics. The actual hard problem is running many of these sessions concurrently, each with its own full application-specific lifecycle: spinning up the presenters' call, the observer, and the chunking pipeline together when an event starts, and tearing all of it down cleanly when it ends, for however many events happen to be running at once. That's the problem our architecture actually solves.

What we built

The result is what we now call ERTSA, our Elastic Real-Time Serverless Architecture: compute that only exists while an event is actually running. AWS Lambda orchestrates EC2 warm pools to spin up a dedicated, ephemeral set of nodes, the call, the observer, the chunking pipeline, for each event on demand, and tears all of it down cleanly when it ends. No idle fleet sized for the worst case; no manual capacity planning per event.

The result

The result is a system where each session, webinar, stream, or otherwise, has a predictable cost. Server-side processing is agnostic to the number of viewers, and nearly agnostic to the number of presenters: a spike in audience size doesn't touch the session's compute at all. The real variable is network cost, and that's exactly what HLS chunking and proper cache management cut down sharply compared to a WebRTC session.

ERTSA adds isolation on top of that: each session runs in its own environment, so a spike in concurrent sessions doesn't affect the latency or functionality of any of them, new or already running.

Where real media expertise could take this further

Our own focus on this project was the architecture itself, the distribution layer, not the user-facing features it opens up. A couple of those are worth naming here, because they're a natural next step once that underlying plumbing is solid:

Pulling a viewer into the call. Right now, the audience only ever watches. But there's no technical reason a presenter or admin couldn't select someone from the chat or the viewer list and invite them directly into the small WebRTC call itself, turning a passive viewer into an active participant for a moment. That's a meaningfully more interactive kind of event, and it's a natural extension of the architecture already described above.

Events synchronized to the video, not the clock. Say a presenter triggers something time-sensitive mid-stream, a promotion or a call-to-action. Firing it at that instant, by system time, means viewers see it at wildly different points in their own playback, because HLS's latency is variable by nature. The fairer approach is to key the trigger to each viewer's own local position in the video timeline instead of wall-clock time, so everyone experiences it at the same point in what they're watching, regardless of how delayed their own stream happens to be.

The harder part isn't firing the trigger fairly; it's fairly gathering and ordering whatever viewers do in response to it. If an event rewards, say, the first ten people to respond, ranking by raw arrival time at the server just rewards whoever happened to have the lowest latency, not whoever actually reacted fastest: someone watching with more delay could still have reacted in half the time. Doing this properly means measuring each response relative to when that specific viewer received the trigger in their own stream, not by when the response lands on the server; a relative queue, not a simple one. Genuinely harder than it sounds, but solvable, not impossible.

A familiar pattern, for a different reason

Worth pausing on: nobody asked for an "invisible participant" in this use case; nothing in the requirements mentioned one. It shows up anyway, because it's simply what the chosen architecture needs; a silent presence in the room to capture what gets chunked out to the audience, not a feature anyone specifically requested. The same pattern behind audit-without-presence turns up again here for an entirely different reason: not compliance, but plumbing. That tends to be a good sign you're looking at a genuine architectural building block rather than a one-off feature; it keeps showing up on its own, for reasons that have nothing to do with each other.