Video Streaming Architecture Diagram: Upload, Transcode, Package, Deliver

"Design YouTube" is a favorite system design question because the interesting parts are not where people expect. The web servers are ordinary. The hard work is moving gigabytes from a phone into storage reliably, turning one upload into a dozen versions that play on every device and connection, and serving those bytes from a CDN so your own servers barely see them.

This post walks through that pipeline in order: upload, transcode, package, deliver. It ends with an architecture diagram you can adapt, and the decisions worth writing on it.

Two systems, not one

A video platform is two systems that share a database:

• Ingest: creators upload; the platform transcodes and packages. Latency is measured in minutes and nobody minds.
• Playback: viewers press play; the first frame has to appear within a couple of seconds and must not stall.

Draw them as two lanes. They scale on different signals (uploads per hour versus concurrent viewers) and fail differently.

Upload: never through your API servers

Video files are large and mobile connections drop. Two rules follow:

1. Upload straight to object storage. The upload API authenticates the creator, creates a video record and returns pre-signed URLs. The client sends the bytes to the bucket directly. Your API never proxies gigabytes.
2. Make it resumable. Use multipart uploads so a dropped connection retries only the failed part. Amazon S3 multipart upload, for example, uploads parts independently and assembles them when the client completes the upload.

When the upload completes, the storage event (or the client's completion call) puts a transcode job on a queue.

Transcode: one upload, an adaptive bitrate ladder

Players switch quality based on bandwidth, so you encode each video several times: an adaptive bitrate (ABR) ladder. A typical ladder runs from around 240p or 360p up to 1080p or 4K, each with its own bitrate.

Transcoding is CPU heavy and embarrassingly parallel:

• Split the source into chunks of a few seconds, at keyframes.
• Encode every chunk and every rendition as an independent job on a worker fleet, usually with FFmpeg.
• Stitch the results, or keep them as segments.

A two-hour film then transcodes in minutes instead of hours, and a failed job retries one chunk. Make jobs idempotent by keying them on video, rendition and chunk, so a retry overwrites instead of duplicating.

One ladder for all content wastes bits: a static slide deck needs far less bitrate than a football match. Netflix popularized per-title encoding, which picks the ladder per video based on its complexity. You can start with a fixed ladder and move to per-title later.

Package: HLS, DASH and CMAF

Players do not download one big file. They read a manifest that lists renditions and segments, then fetch segments of a few seconds each over plain HTTP.

CMAF is why the packager matters: with it, you store one set of segments and write two manifests instead of two copies of every video. Short segments start faster and switch quality sooner; longer segments cost fewer requests. Apple's HLS authoring specification lists concrete recommendations for segment duration, keyframes and ladders.

Paid content adds DRM. The packager encrypts segments once with common encryption (CENC), and each platform's DRM system (Widevine, FairPlay, PlayReady) issues licenses to players through a license server.

Deliver: the CDN does the work

Segments are static files, which is the whole point: a CDN caches them close to viewers, and a popular video is served almost entirely from edge caches. The origin is the renditions bucket, often behind an origin shield so a cache miss in 50 edge locations becomes one request to storage.

The playback API stays small: check that the viewer may watch the video, return a manifest URL (signed if the content is private), and record playback events for analytics.

Live streaming is a different pipeline

Live video reuses the packaging and the CDN but replaces the ingest. An encoder pushes a stream over a protocol such as RTMP or SRT to an ingest server, which transcodes the ladder in real time and writes new segments every few seconds. Latency comes from segment length plus the player's buffer; low-latency modes of HLS and DASH deliver parts of a segment before it is complete to get closer to a few seconds. Keep live and on-demand as separate pipelines that share the CDN, the player and the metadata.

The architecture diagram

How to read it:

• Top lane, ingest: the creator gets an upload URL from the upload API (1), uploads parts straight to the raw uploads bucket (2), and the completed upload queues transcode jobs (3). Workers encode the ladder, and the packager writes segments to the renditions bucket and marks the video ready in the metadata store.
• Bottom lane, playback: the viewer asks the playback API for a manifest URL, then streams segments from the CDN. A cache miss reads from the renditions bucket.
• DRM is dotted because only protected content needs it: the player fetches a license from the license server.
• The Markdown block shows an example ladder. Your numbers should come from your content and your viewers' bandwidth.

What to put on the diagram

• Where the bytes flow. Draw uploads and segments going to storage and the CDN, not through your API.
• The job unit. "One job per rendition and chunk" tells reviewers how retries and parallelism work.
• Formats and protection. Name HLS, DASH or CMAF, and DRM if you use it.
• The ready signal. A video is not playable until packaging finishes; show where that state lives.

The same queue-and-workers shape appears in the event-driven architecture post. For the cloud side, the AWS multi-region architecture diagram covers serving from more than one region, and the serverless architecture diagram shows how storage events can trigger functions instead of a worker fleet.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add two Person nodes from the C4 Model pack for the creator and the viewer.
3. Add Container nodes for the upload API, transcode workers, packager and playback API, and a Database for video metadata.
4. Add two Object Storage nodes and a CDN from the Cloud pack, a Queue from the Data pack for transcode jobs, and an External System for the DRM license server.
5. Draw ingest in the top lane and playback in the bottom lane, number the upload steps on the edges, and add a Markdown block from the Core pack with your ladder.

The example uses 13 diagram nodes, within the Free plan.

FAQ

What is an adaptive bitrate ladder? The set of renditions a video is encoded into, each with its own resolution and bitrate. The player picks the best one the viewer's connection can sustain and switches as bandwidth changes.

Should I use HLS or DASH? Often both. Package once as CMAF segments and write an HLS and a DASH manifest, so Apple devices and other players are covered without storing two copies.

Why upload directly to object storage? Large files through your API servers tie up connections and memory, and a dropped connection restarts the upload. Pre-signed multipart uploads go straight to storage and resume part by part.

How is transcoding parallelized? Split the source into chunks at keyframes and encode each chunk and rendition as a separate job, then stitch or package the results.

Do I need a CDN for video? For anything beyond a small audience, yes. Segments are static files, and a CDN serves repeated requests from caches close to viewers instead of from your storage.

Start free — one seat, no credit card.