Designing a video streaming platform

A video streaming platform looks like storage plus playback. Then you trace one viewer's session from clicking play to the credits, and it stops looking simple. The system has to swallow large uploads, turn them into playable renditions, serve tiny segments reliably to a phone on a 4G connection, keep search and browsing fast, enforce who's allowed to watch what, and pull quality and cost signals out of all of it — without ever putting analytics or rights checks onto the segment fetch path.

The mistake is to optimize the parts in isolation. Your CDN can make media cheap and close to viewers, while playback still takes four seconds to start because the manifest call crossed a continent. The transcoder fleet can produce beautiful HLS ladders, while failed jobs, oversized renditions, search, and continue-watching all hammer the same database. The rights check can be perfectly correct, and far too slow or too brittle to run on every segment fetch. A real design pulls those workloads apart on purpose.

• Functional: upload videos, transcode into adaptive renditions, publish playable manifests, browse and search a catalog, track watch progress, enforce subscriptions and territory windows, and measure playback quality.
• Non-functional: start playback in under 2 seconds at p95, keep playback starts reliable through retries and regional read models, serve high-volume media through CDN cache, control egress/transcoding/storage cost, process uploads asynchronously with retries, and protect premium content without adding a database call to every segment fetch.

Those headline numbers turn into specific capacity slices the design has to absorb. Segment fetches: at 1M concurrent streams and 4-second HLS segments, you're serving roughly 250k segment GETs/sec (1M / 4), nearly all of them from CDN cache. CDN miss budget: at a 99.5% hit rate, that's about 1.25k segment requests/sec hitting origin shield; size for 5× burst headroom around regional cache fills. Transcode throughput: 100k uploads/day averages around 1.2 jobs/sec, but realistic peaks are 5–10× that, and each job fans out to roughly five renditions with real-time-factors between 0.25× and 1× depending on resolution. Plan on 50–200 concurrent encoder slots with elastic burst capacity, and design the queue to drain in under 30 minutes at p99 so the processing → ready window stays tight. Startup latency budget (2s p95): roughly 200 ms manifest, 100 ms entitlement, 200 ms DRM license, 400 ms first segment, plus about 1.1s of slack for DNS, TCP, TLS, and ABR ramp-up. Each of those is its own SLO to hit, not one big budget to spend however you like.

This case study runs six iterations instead of the usual five. The reason is that video streaming has two separate late-stage moves and bundling them into one obscures both: first getting playback startup regional so global viewers don't go transcontinental for a manifest, and then adding the rights, reliability, and cost loops a licensed platform actually needs to operate.

Start with the naive version. One application server takes uploads, drops the file on local disk next to its metadata row, and serves byte-range GETs back to viewers. For a prototype this is fine — the control path and the data path are the same thing.

It collapses the moment one video gets popular. Video bytes are orders of magnitude heavier than metadata, so a single hit title can saturate the same network and CPU that login, browsing, upload, and playback-start are all trying to share.

Push the media into object storage and put a CDN in front of it. The API keeps metadata and hands out signed playback URLs; viewers pull the video bytes through the CDN. That's the first real split: the app servers stop being the place media fails, and the expensive part of delivery moves onto infrastructure designed for cache hit rate and egress control.

Once the original lands durably, emit a transcode job and let the upload request finish. Workers pick the job up, generate the bitrate ladder, HLS/DASH manifests, thumbnails, captions, and sidecar files, then publish the packaged output to the CDN. Now the upload isn't blocked on encoding, a failed job can retry against the raw original, and clients can pick a rendition that doesn't waste their bandwidth.

Once playback itself is reliable, product traffic starts to take over. Browse pages, search, home rails, continue-watching, recommendations — none of these should be running through the playback API or hammering the primary metadata database. Move them into their own lanes: a catalog API on its own read store, a search index, a recommendation service with its own feature data, and a watch-event stream for engagement signals. One expensive product feature should never be able to take playback down.

The CDN serves media globally, but starting playback still requires a few control-plane decisions: is this title available in your region, which manifest do you get, are you entitled to it, what's your session id. Push those reads into regional playback APIs backed by replicated catalog snapshots and local event buffers. Origin media stays authoritative; catalog writes still go to one place.

The last version adds the controls a licensed streaming platform actually needs before you can run it safely: an entitlement service, a rights ledger, DRM license exchange, forensic watermarking, playback observability, and a cost governor that nudges cache TTLs, origin shielding, and bitrate policy through guarded feedback rather than ad-hoc changes during incidents. Segment fetches stay CDN-fast. Rights, reliability telemetry, and cost analytics all shape what happens around the session, not what happens during a segment GET.

v6 is production-grade for licensed video-on-demand. It doesn't cover live streaming, ultra-low-latency sports, offline downloads, creator monetization, ad insertion, comments, or royalty settlement. Each of those shifts the reliability model and the cost profile enough to deserve its own design pass.

It also keeps authoritative catalog and rights writes centralized. That's deliberate for this scope. Regional read models keep playback fast; centralized writes avoid the conflicts you'd otherwise hit around release windows, partner takedowns, and rights audits.

Archie's reviews walk the design through the workload boundaries that actually matter for streaming. Pull media bytes off the app servers. Push CPU-heavy transcoding off the request path. Split product discovery away from playback. Move startup reads into regions. Then close the loop with rights, reliability telemetry, and cost controls.