Scaling Live Video to Millions

Live Streaming Architecture Lessons From Cam Platforms

Some of the busiest live video operations on the internet are the ones engineering blogs never write about. In late 2021 the camming site BongaCams sat around the 37th most visited website in the world. Chaturbate pulls in roughly 117 million visits a month and has spent years near the top of global traffic charts, next to LiveJasmin, which has been sending live video down consumer connections since 2001, back when most people still associated "streaming" with a spinning buffer icon. These platforms push millions of concurrent viewers at thousands of separate live broadcasts at the same time, and they do it with delay low enough that someone can tip a performer and watch the reaction land a fraction of a second later. That mix, many simultaneous live sources plus real-time interaction plus mass scale, is one of the genuinely hard problems in live streaming architecture. The design choices underneath it, WebRTC vs HLS, transcoding ladders, edge delivery, video transcoding at scale, are the same ones every interactive video product eventually smacks into. Cam platforms just hit the wall first, and without the option to fail quietly.

It helps to understand why this is a different problem, not a smaller version of Netflix. When you watch a film on a streaming service, the video was encoded once, months ago, and copies of every quality level already sit on servers close to you; delivery is a solved caching problem, and one edge server fills its cache once and then serves the same bytes to thousands of people from memory. A live sports broadcast is harder, because the content is made in real time, but the shape is still friendly: one source, or a handful, feeding an enormous audience. Cam platforms live in the opposite corner. There is no single feed. Thousands of performers are online at once, each a unique live source, each watched by anywhere from a handful of people to a few thousand, and the whole product is the interaction. A recorded show would not sell. People pay to type something and get a response, or to open a two-way video session, and that only works if the delay between camera and screen stays under a second. So the industry ended up needing three things at once that pull against each other, low latency, thousands of concurrent inputs, and mass scale, on margins thin enough that wasted compute is the gap between profit and loss. The caching trick that saves everyone else barely helps, because unique low-concurrency streams give an edge server little to reuse.

The pipeline: ingest, transcode, deliver

Every live platform runs the same three-stage journey. A broadcaster's camera feed comes in, gets converted into multiple quality versions, and those versions go out to viewers. The engineering lives in the details of each stage and in which protocol you choose where.

Ingest is where the broadcaster's stream arrives, and for years the default was RTMP, the protocol Adobe built for Flash. It survives on the sending side long after Flash died on the receiving side, mostly because software like OBS speaks it and it just works. Newer options crowd in around it. SRT runs over UDP with its own retransmission logic, which makes it steadier over flaky connections. WebRTC and its ingest cousin WHIP let a browser broadcast straight from a webcam with no extra software, which matters enormously for cam work, where a performer's setup is often a laptop and a phone rather than a studio. Whatever the protocol, the ingest layer has to be forgiving: if a broadcaster's home connection stutters for two seconds, you do not want to kill the stream and force a reconnect that empties the room, so the usual pattern is to buffer the gap, keep trying, and only give up after ten or fifteen seconds. Placement matters too. A performer in Bucharest and a viewer in São Paulo should both land on infrastructure near them, which pushes platforms to run ingest points and relay servers across regions rather than in one data center, if only to keep the round trip short enough for the interaction to feel live.

Then comes transcoding, and this is where cam economics bend away from everyone else's. That single incoming feed, usually 1080p at 60 frames per second, has to become a ladder of lower quality versions so viewers on weak connections get something watchable instead of a frozen frame. A typical ladder runs 1080p, 720p, 480p, 360p and 240p, and producing it eats real compute, roughly four to six CPU cores for one stream done in software. The rungs also have to be built carefully. Keyframes need to line up across renditions so a player can jump from 720p to 360p mid-stream when a connection sags, without a visible stutter, and segment length is a direct latency lever, since shorter segments cut delay but multiply the number of requests and the overhead. Codec choice is its own tradeoff: H.264 plays everywhere and encodes cheaply, while VP9 and AV1 squeeze the same quality into far less bandwidth but cost much more to encode unless you have hardware that supports them. The point that defines the industry is that all of this happens once per stream regardless of how many people watch. A stream with ten viewers and a stream with ten million cost the same to transcode. For a sports broadcast that is a rounding error, one ladder feeding a stadium's worth of viewers. For a cam platform it is the main event, because there are thousands of ladders running at once and each is watched by comparatively few people, so the cost you cannot spread across a big audience is precisely the cost that dominates.

Twitch, which is not a cam site but faces a milder version of the same shape, made this visible. Early on the platform could only afford to transcode two or three percent of its channels; everyone else got the broadcaster's raw feed or nothing, which meant a viewer on a phone watching a small streamer often got a feed their connection could not handle. Twitch eventually built custom transcoders on AMD Xilinx FPGAs that ran the job around thirty times faster than a general purpose CPU for the VP9 codec, and only then could it transcode every channel. That arc, from "we can only do this for the popular streams" to "we can do it for all of them," is the whole cost story of many-source live video compressed into one company's history, and cam platforms never had the luxury of the first phase, because a private show that stutters does not get paid for. The numbers explain the urgency. On managed cloud transcoding the bills are punishing at volume, but self-managed hardware rewrites the math: an NVIDIA T4 GPU handles several adaptive bitrate ladders at once, dropping the cost per stream to a small fraction of a dollar an hour, and purpose-built video ASICs from vendors like NETINT push the amortized cost down to a couple of cents per stream per hour. One infrastructure team, Mayflower, documented moving ten thousand simultaneous streams off five hundred CPU servers and onto thirty-eight ASIC-equipped machines, cutting the capital cost per stream from around a thousand dollars to roughly a hundred and forty, and the power draw from 325 kilowatts to 34. The contrast with broadcast is the whole point. For a single huge event, transcoding is trivial and bandwidth is the bill; for a wall of small simultaneous rooms the bill flips, and the transcode farm becomes the thing you optimize until it hurts. When the business is thousands of concurrent inputs, that is not an optimization. It is whether the company exists.

WebRTC versus HLS, and the hybrid nobody advertises

Delivery is where the protocol wars get decided, and the deciding factor is latency. Standard HLS, Apple's method of chopping video into small files served over ordinary web infrastructure, is a fine fit for scale because any CDN can cache and distribute those files to millions of people. Its weakness is delay: traditional HLS runs anywhere from six to thirty seconds behind live because the player waits for whole segments to arrive. Low-latency HLS and chunked CMAF trim that to a few seconds by shipping partial segments, good enough for a concert or a match. The same encoded rungs get wrapped once into CMAF fMP4 segments and handed to both HLS and DASH players, which keeps packaging cheap, and the last slice of delay is often a client-side choice, since a player such as hls.js holds a buffer that trades roughly a second of latency for protection against a network hiccup. None of it is fast enough to hold a conversation. WebRTC is. Built for video calls, it abandons the file-and-fetch model entirely and pushes media as it is captured, over UDP, reaching glass-to-glass delays of roughly 300 milliseconds and often less. That is the difference between an exchange that feels live and one that feels like a satellite phone call, and for a platform whose revenue depends on tipping and an immediate reaction, or on a two-way session, sub-second delay is not a nice extra. It is the product.

WebRTC's problem is that it was designed for small groups, not stadiums. In raw peer-to-peer form it falls apart past ten or twelve participants, since every viewer would need a direct connection to the source, and getting even that connection established means punching through home routers with ICE, STUN and, when direct paths fail, TURN relays that carry the media themselves and quietly add a bandwidth bill of their own. The fix for scale is a Selective Forwarding Unit, a server that takes the broadcaster's stream in once and forwards copies out, so the performer's laptop only ever uploads a single feed. An SFU is cheaper and lower latency than the older Multipoint Control Unit approach, which decoded and re-mixed a fresh stream for every viewer and choked on CPU. To reach large audiences, platforms chain SFUs into cascading trees, one server feeding the next, which pushes WebRTC delivery up toward a million concurrent viewers; beyond that the limit is not the tree shape, which can grow indefinitely, but the cost of running that many media servers and the pain of keeping them healthy. When one node dies, the viewers hanging off it must reconnect to a sibling without disturbing the rest, the same fast-reroute and health-check discipline CDN engineers have practiced for decades. A quiet trick keeps the whole thing affordable: simulcast, where the broadcaster sends two or three quality levels up at once and the server simply picks the right one per viewer instead of transcoding on the fly, trading a little of the performer's upload bandwidth for a large saving on server compute. It is one of those unshowy decisions that separates a platform that is profitable from one that is merely impressive.

In practice almost nobody picks one protocol and lives with its downside. The dominant pattern is a hybrid: WebRTC for the first mile, broadcaster to ingest, and often for the interactive core audience, while the same media gets repackaged as HLS or CMAF and pushed through a CDN for everyone who is only watching. The people in the room tipping and chatting get the low-latency real-time path; the long tail of passive viewers gets the cheap, endlessly scalable one. That division is also where the margin is recovered, since the passive tier rides ordinary CDN egress, billed per gigabyte and heavily discounted at volume, while only the smaller interactive audience carries the expensive real-time path. The tuning targets that keep this honest are well known to anyone who has run it, time to first byte under 200 milliseconds, playback starting within two seconds of a click, packet loss under one percent, and they are watched on live dashboards because a viewer who waits five seconds for video to appear often just leaves. Newer protocols are trying to collapse the split entirely. Media over QUIC aims to match WebRTC's speed while scaling like HTTP, and a few providers already run it in production. For now the hybrid is what ships, and cam platforms were assembling versions of it long before live shopping and creator watch parties made the same requirements fashionable in mainstream tech.

The stage most outsiders forget is everything wrapped around the video. A platform hosting thousands of live, user-generated streams cannot review them by hand, so computer vision models scan frames in real time to flag anything that breaks policy or law, an unglamorous but non-negotiable part of the build, and one that has to run across every stream at once without adding the kind of delay that would ruin the interaction. The economics force pragmatism here as much as anywhere: with thousands of streams live at once, running a heavy model over every frame of every one is too expensive, so platforms sample frames, use cheaper models for a first pass, and escalate only the uncertain cases to a human review queue. The discovery layer leans on machine learning too, generating live preview thumbnails and steering viewers toward rooms they are likely to stay in, because a stream with no audience earns nothing and still costs a full transcode. Underneath sits payment infrastructure hardened against fraud and chargebacks to a degree most online shops never need, because the adult industry has been a favored target of card fraud for as long as it has taken cards. None of this is video engineering in the narrow sense, but it is inseparable from making live video pay, and it is why the teams behind these sites end up fluent in distributed systems, real-time machine learning and adversarial security all at once.

Which raises the part that tends to go unsaid. The adult industry has a long record of solving hard internet problems first and getting no engineering credit for it, from early streaming video to online payment processing to moderation at scale, and the stigma means the write-ups do not get published, the conference talks do not get given, and the résumés stay vague. The skills are real and they transfer directly. Real-time video for many simultaneous sources, fraud detection under constant attack, automated moderation across a live firehose, all on margins that punish waste, is a precise description of what live commerce platforms, creator-economy startups and interactive streaming products are now paying good money to figure out. Plenty of the engineers who solved it the first time moved on to companies with cleaner logos and simply never mention where they learned the trade. The useful lesson here is not really about cam sites. It is that the interactive live video problem the industry keeps treating as new was worked out years ago, in a corner of the web most of the field would rather not read about, by people who could not afford to get it wrong.