Three shapes of video platform

Ask what a video platform is and you will get a box diagram: upload, transcode, store, CDN, player. It is a fair sketch of one kind of platform. Applied to the other two, it gets the hard part wrong every time.

The useful question is what each platform is short of. For a premium catalog it is egress capacity at peak. Live runs short of time. A user-upload service has too many videos to spend effort on any one.

Premium on-demand has time and a small catalog

A subscription catalog is small, expensive to produce and watched by a large share of the audience on the same evening. Most requests are for a title that is popular right now. Encoding can take hours, because nobody is waiting for it, so the pipeline can afford slow, high-quality encodes with a ladder tuned per title.

The hard part is the read side. In Platform Architectures Lab, the SVOD archetype states it directly: peak-hour egress, answered by pre-positioning, which means pushing the catalog out to appliances inside ISPs overnight so that prime time never touches the origin. Its graph starts at a mezzanine ingest and a QC step, then runs through an encode farm and packaging with DRM. At the far end sit ISP edge appliances, and a separate node for fill traffic, because moving the catalog is a scheduled job and not a reaction to a request.

This platform is read-heavy by a wide margin. Every design decision serves the second hundred million plays of the same few thousand files.

Live has no time at all

Live inverts the budget. There is no finished file, so there is no slow encode, and a segment that arrives late is a stall or added latency. The Live UGC archetype in the lab is Twitch-shaped: an ingest point for each streamer, live transcoders, a live packager and an origin, with chat fan-out alongside and a VOD archive behind. Its stated hard problem is fan-in as much as fan-out. Every streamer needs an ingest point and a transcoder slot right now, most channels have fewer than ten viewers, and chat load grows with viewers times messages.

That is write-heavy in an unusual way. The scarce resources are allocated per channel and not per viewer, so channel count matters as much as audience. Caching works differently too, since a live segment is only useful until it leaves the playlist window. Chat is write traffic of its own, and the lab's chat explainer puts automod, rate limits and slow mode ahead of publishing.

Latency is the other axis, and it is a product choice. The Media Network Lab has a latency mode card with the lab's own figures:

The card's notes add what each costs. Short segments mean more requests per viewer and lower hit efficiency. LL-HLS needs a part-aware player and an edge that supports blocking reloads. WebRTC scales by adding SFUs, not caches.

Lower latency removes the thing that made scaling cheap. Segments can be cached and shared, and packets cannot. The Real-time archetype says so in its tagline: sub-300 ms, many-to-many, no CDN in the path. What gets hard is NAT traversal and simulcast layer selection, plus cascading rooms across regions.

User uploads have scale per video

UGC VOD looks like on-demand, with an upload API (resumable sessions, and a virus scan listed on the node), a raw bucket and a job queue feeding a transcode fleet. The difference is the population: millions of uploads a day, most watched rarely. The lab calls it a long-tail catalog, where the cache hit ratio is low for the tail and the ladder must be cheap to produce.

So the budget flips again. A premium platform spends effort per title because each title earns it back. A user platform cannot afford heavy effort for everything. The transcode node's subtitle reads per-title ladder, VP9 or AV1 for popular. So every upload gets a per-title ladder, and the heavier codecs are a bet placed after a video shows it will be watched.

Open ingest has a second cost. Anyone can send anything, so the check sits at the door: the lab's Upload API node lists a virus scan, and the simulation does not model the order of steps.

Running the same graphs

Each archetype in the lab is a plain graph of nodes and wires. A compile step turns every node into one simulation node on media-sim's engine tier, because archetypes are arbitrary graphs and the fixed region model does not fit them. You pick an audience of 20 to 2000 simulated viewers (200 by default) and a curve. Steady is flat. Flash crowd stays flat for 20 seconds, then triples over the next 20. Each run covers a 300 second window.

The point of running them is to see which node strains first on each shape. I would rather you find that out on a graph than on a launch night.