EN 中文

System Design Lab

A video platform is really two systems: a compute-heavy transcode pipeline on ingest and a massively read-heavy CDN on playback.

Change uploads per day, average video length, concurrent viewers, catalog size, how many bitrate renditions you encode, the peak multiplier, and regions. The design moves from a single box that serves files directly, to CDN offload, to a queue plus a transcode worker farm, to sharded object storage with a separate metadata store, and finally to multi-region multi-CDN delivery.

Read the full tutorial

Guided walkthrough

Reason about it one step at a time

Each step sets the workload below - watch the diagram, meters, and decisions react.

Normal evolution scenarios

Click left to right for the intended demo path. Each card changes the workload inputs.

Workload

These are inputs, not preset architecture stages.

Recommended shape

Current architecture path
Video streaming platform architecture diagram Whiteboard-style architecture diagram for a video platform: clients, edge CDN delivery, an upload and API tier, a transcode queue with a worker farm, and object storage with a metadata database. Clients Edge / CDN Upload + API Transcode Storage Viewer playback Uploader creator CDN serves segments Multi-CDN global delivery Upload + API ingest + playback Packager HLS / DASH Job queue async work Worker farm encode renditions Live encoder real-time Object store video files Metadata DB catalog rows
Clients
Viewer requests a manifest and streams video segments, switching bitrate as bandwidth changes
Uploader submits a new source video to be transcoded and published
Edge / CDN
CDN caches video segments at the edge so the origin is spared the bulk of playback egress
Multi-CDN spreads delivery across regions and providers for capacity and low startup latency
Upload + API
Upload + API accepts uploads, serves manifests, and resolves metadata for playback
Packager segments and packages renditions into adaptive manifests for the player
Transcode
Job queue buffers transcode jobs so ingest spikes never block uploads or playback
Worker farm fans one source video into every bitrate rendition in parallel
Live encoder transcodes live ingest in real time with no chance to re-encode
Storage
Object store durably holds source videos and every encoded rendition as the playback origin
Metadata DB stores titles, manifests, and per-video metadata that playback looks up

Bottlenecks

CDN offload / origin egress

Transcode backlog

Object storage size

Metadata QPS

Global delivery latency

Why this changes

    Decision tradeoffs

    CDN delivery

    Transcode pipeline

    Adaptive bitrate

    Object storage

    Metadata store

    Multi-region / multi-CDN

    Source-backed rules

    These are the durable system-design claims behind the model. The exact slider thresholds are deliberately labeled as teaching assumptions.

    Verified rule

    Streaming video is delivered from CDN caches, not the origin

    A CDN caches segments at edge locations near viewers; the origin only serves cache misses, which is the only way playback egress scales.

    AWS CloudFront
    Verified rule

    Adaptive bitrate streaming packages multiple renditions for the player to switch between

    HLS (and DASH) describe a media playlist of segmented renditions so the player picks a bitrate that fits current bandwidth; this is why ingest must encode several profiles.

    Apple HTTP Live Streaming
    Verified rule

    Transcoding is run as asynchronous jobs on a worker farm fed by a queue

    File-based transcoding is submitted as jobs and processed by elastic workers, so upload spikes queue up instead of blocking the request path.

    AWS Elemental MediaConvert
    Verified rule

    Object storage is the durable, scalable origin for media files

    Source videos and every rendition live in object storage, which scales storage and durability independently of the compute and serving tiers.

    Amazon S3

    Teaching assumptions

    • Playback bandwidth is modeled as concurrentViewers x peak multiplier x ~5 Mbps; CDN offload assumes hot content caches well at the edge.
    • Transcode compute is approximated as profiles x source minutes x a fixed factor per worker; real encoders vary by codec and resolution.
    • Storage counts source plus renditions per video; single-node QPS, egress, and storage budgets are conservative teaching numbers, not vendor limits.