Skip to content
Devgo

YouTube

Global video upload, processing, and streaming at scale

YouTube handles petabytes of video upload and billions of views daily. The architecture separates upload, async processing (transcoding to multiple resolutions), and playback via -cached adaptive streaming. Storage is object-based; a metadata DB tracks videos.

Product constraints

  • Huge upload volume and size; uploads must be resumable and tolerant of flaky networks.
  • Playback must adapt to bandwidth and device (adaptive bitrate).
  • Global low-latency start; -cached, not origin-served.
  • Long tail of content; most views hit a small hot set.

High-level diagram

YouTube architectureA block diagram of the YouTube system's main components and request flow.ClientUploadresumableQueueObject storesourceTranscodersMetadata DBCDN
Illustrative block diagram of YouTube. Not to scale; see the request path below for flow.

Request path

  1. Upload. Client resumable-uploads to an upload server; chunks stored to ; a metadata record is created in the DB.
  2. Processing. A queue triggers transcoders that encode the source into multiple resolutions/ codecs and generate thumbnails; outputs go to .
  3. Publish. Metadata (resolutions, thumbnails, duration) is written; the video becomes playable.
  4. Playback. Player requests a manifest; serves the chosen rendition from the edge; origin/ is the cache miss source.

Data model

Video metadata (id, title, owner, duration, resolutions, status) in a relational/sharded DB; the actual media lives in keyed by video id + rendition. Thumbnails and manifests alongside. View counts and engagement in a separate, eventually-consistent store.

Storage / cache / queue choices

Storage

(S3-like) for media; sharded relational DB for metadata; for playback.

Cache

edge cache for renditions; / for hot metadata and manifests.

Queue

Message queue ( or -like) to drive async transcoding jobs.

Scaling levers

  • absorbs the vast majority of playback; origin only sees misses.
  • Shard metadata DB by video id; read replicas for listing.
  • Parallelize transcoding across many workers; encode renditions independently.
  • Adaptive bitrate shifts load to the right rendition per client.

Copy vs skip (for a smaller team)

Copy
  • Separate upload from processing via a queue.
  • Store media in object storage, metadata in a DB.
  • Serve playback through a CDN with adaptive bitrate.
  • Make uploads resumable (chunked).
Skip
  • Multi-region live transcoding pipelines (overkill until huge scale).
  • Custom CDN (use a managed one).
  • Global anycast for upload (use regional endpoints).

, ,

Sources