Guide

A video product is two systems that share an object store. The write path turns one uploaded file into many renditions and short segments. The read path barely touches your data center. The player fetches a small manifest, then a steady stream of segments from a CDN edge near the viewer.

The asymmetry is extreme. A popular title may be watched around 100,000 times for every upload. You pay once at upload, in CPU and storage for every rendition, so each view becomes a cache hit with a fast start. This page covers on-demand video. Live streaming uses a different ingest path.

Requirements

  • Upload videos lasting minutes to hours, and survive flaky mobile networks.
  • Encode a bitrate ladder, from 240p up to 4K.
  • Start playback in under about 2 seconds, worldwide.
  • Serve millions of concurrent viewers. Egress cost dominates the bill.

Concepts in this topic

StepConceptWhat it answers
1Video segments and manifestsHow is one video split into files a player can fetch?
2Transcoding as a DAGHow do you encode many renditions in parallel?
3Adaptive bitrateHow does the player pick quality as the network changes?

Upload path

Do not stream gigabytes through your application servers.

  1. The client asks the upload API for a video ID. The metadata row starts as uploading.
  2. The API returns presigned multipart URLs for object storage.
  3. The client uploads parts directly and retries only the parts that failed.
  4. On completion, the API checks size and checksum, marks the video processing, and enqueues a job on a queue.

Resumable uploads matter more than fancy encoders at this stage. A creator on hotel Wi-Fi needs the upload to pick up where it stopped.

Playback path

The playback API checks authorization and returns a signed manifest URL. The player does the rest: it downloads the master manifest, picks a starting rendition, fetches segments in order, and adjusts quality at each boundary.

CDN strategy

Video bytes are the textbook CDN workload: immutable, cacheable and heavily shared.

  • Pre-position hot titles at the edge. Netflix goes further and places caches inside ISP networks, through its Open Connect appliances.
  • Pull long-tail content from origin on first request, behind an origin shield so a miss storm does not reach the object store.
  • Sign URLs so manifests cannot be shared indefinitely.

A startup usually buys a CDN and designs for a high hit ratio. See CDN hit ratio and cost.

Cost

Storage is a one-time cost per rendition. Egress is continuous, and for popular content it dominates.

1 GB streamed to 1,000,000 unique viewers ≈ 1 PB of egress

Encode spend is front-loaded, but egress keeps growing as long as people watch. A codec that cuts bitrate by 30% can pay for its slower encode. Move rarely watched titles to cheaper storage.

Metadata and views

  • The metadata database holds title, owner, status and manifest URLs. Owners need strongly consistent reads. Public watch pages can use a cache.
  • View counts are approximate and batched. Players send heartbeats to a stream, and a job aggregates them. Never run one UPDATE per play.
  • Recommendations consume watch events asynchronously. Playback never waits for them.

DRM

Platforms usually encrypt segments with a DRM system such as Widevine, FairPlay or PlayReady, applied during packaging. The license server joins the startup path, so it must be highly available.

Failure modes

FailureMitigation
Upload fails at 90%Multipart resume; completed parts are not resent
Worker preempted mid-encodeIdempotent tasks keyed by video, chunk and rendition
Bad encodeHold ready, alert, and allow re-queueing
New episode floods originPre-warm edges, use a shield, rate-limit miss fills
Manifest leakedShort-lived signatures, revoke on takedown

A ready status should mean the player can fetch every file it may request. Sidecars such as thumbnails, subtitles and alternate audio are outputs of the same pipeline, and the manifest should leave out anything that is missing.

Metrics

Track time to first frame, rebuffer ratio, and CDN hit ratio by region. A spike in rebuffering on one network often means a bad peering path, not an app bug.

Common mistakes

  • Proxying uploads through the app. It ties up servers with bytes they never need to read.
  • Starting playback at the top rung. A 4K first segment can miss the 2-second start.
  • Counting views with one database write per play. At scale, that write rate is unmanageable.
  • Forgetting the storage cost of extra codecs. Each codec adds a full set of files.

Key takeaways

  • Uploads go straight to object storage. Apps enqueue work and do not proxy bytes.
  • Transcoding is a parallel graph over chunks and renditions, with aligned keyframes.
  • HLS or DASH manifests with short segments let ordinary CDNs deliver video.
  • Egress dominates cost, and view counts should be batched.

Further learning

A Netflix engineering talk from re:Invent. It covers how playback, personalization and delivery fit together at scale.

AWS re:Invent 2019: A day in the life of a Netflix engineer (NFX202)AWS Events
Netflix TechBlognetflixtechblog.com ByteByteGo blog (Alex Xu)Explain complex systems with simple terms, from the authors of the best-selling system design book series. Join over 1,000,000 friendly readers. Click to read ByteByteGo Newsletter, a Substack publication.blog.bytebytego.com

Object storage

CDNs and the edge