Design YouTube or Netflix

Architecture Overview

This architecture is designed for a large-scale video streaming platform similar to YouTube or Netflix. The system separates the control plane (metadata, APIs, upload management, orchestration) from the data plane (video storage, transcoding, CDN delivery). This separation allows lightweight API services to scale independently from the bandwidth-intensive video delivery pipeline. Application servers never proxy video files. Instead, clients upload directly to object storage and stream directly from the CDN, allowing the platform to support millions of users without overwhelming backend servers.

The architecture consists of two major workflows:

• Upload Pipeline converts a raw uploaded video into multiple optimized streaming formats.
• Streaming Pipeline delivers those processed videos efficiently using adaptive bitrate streaming.

The entire system is built around asynchronous processing, distributed storage, stateless services, and aggressive caching to maximize scalability while minimizing infrastructure costs.

Upload Architecture

When a creator uploads a video, the application server does not receive the video itself. Instead, the client first requests a pre-signed upload URL from the API service.

The API authenticates the user, creates a multipart upload session in blob storage, stores the initial metadata (title, description, uploader, visibility, etc.), and returns a temporary upload URL. This URL grants permission to upload directly into blob storage without exposing permanent credentials.

The client splits the video into multiple chunks and uploads them directly to blob storage using multipart upload. Because every part is uploaded independently, interrupted uploads can resume from the failed chunk instead of restarting the entire transfer. This significantly improves reliability for multi-gigabyte uploads and removes the application servers from the critical data path.

After all parts have been uploaded, the client completes the multipart upload request. Blob storage assembles the individual parts into the final raw video object.

The creation of the new object automatically generates an object-created event. Rather than immediately processing the video, this event is published to a queue. Using a queue completely decouples uploads from processing, allowing uploads to finish instantly even if the transcoding cluster is busy.

Asynchronous Processing Pipeline

A Transcoding Orchestrator continuously consumes upload events from the queue.

Instead of treating transcoding as a single long-running task, the orchestrator constructs a Directed Acyclic Graph (DAG) representing every processing step and the dependencies between them. This allows independent tasks to execute simultaneously while preserving the required execution order.

A typical DAG contains operations such as:

• Splitting the original video into GOP-aligned segments
• Encoding each segment into multiple resolutions (240p, 360p, 480p, 720p, 1080p, 4K)
• Encoding multiple bitrates for each resolution
• Generating thumbnails
• Creating preview images
• Extracting audio if required
• Applying watermarking
• Creating streaming manifests
• Updating processing status

Once the video has been split into independent segments, hundreds of encoding jobs can execute in parallel across many worker machines. Since transcoding is extremely CPU-intensive, parallel execution dramatically reduces total processing time.

Workers never exchange large video files directly. Instead, intermediate outputs are written back to blob storage, and workers simply pass object references between DAG stages. This minimizes network traffic and allows workers to remain completely stateless.

When all DAG tasks complete successfully, the processed outputs include:

• Video segments
• Adaptive bitrate variants
• HLS or MPEG-DASH manifest files
• Thumbnail images
• Updated metadata

The orchestrator marks the video as available for streaming.

Adaptive Bitrate Video Generation

Raw uploaded videos are not streamed directly.

During transcoding, each video is converted into multiple combinations of:

• Resolution
• Bitrate
• Codec
• Container format

Each version is then divided into short video segments, typically lasting only a few seconds.

The transcoder generates one or more manifest files (such as HLS or MPEG-DASH manifests). Rather than containing video data, these manifests describe:

• Available quality levels
• Segment ordering
• Segment URLs
• Codec information
• Bitrate information

The manifest acts as an index for every streamable version of the video and enables adaptive bitrate streaming.

Metadata Layer

Video files themselves are far too large to store inside a traditional database.

Instead, the metadata service stores only structured information such as:

• Video ID
• Title
• Description
• Upload timestamp
• Duration
• Processing status
• Thumbnail URLs
• Manifest URL
• Owner information

A horizontally scalable database such as Cassandra is used because metadata reads and writes occur at massive scale while requiring high availability and partition tolerance. Records are partitioned using the Video ID, allowing requests to be distributed evenly across database nodes.

Frequently accessed metadata is cached inside Redis.

Most video requests first check Redis. If metadata is already cached, the database is bypassed entirely. Otherwise, the metadata is loaded from Cassandra and inserted into Redis for future requests.

This cache dramatically reduces database load for popular videos.

Streaming Architecture

When a viewer opens a video, the client first requests video metadata from the API service.

The metadata contains information such as the title, description, thumbnail, duration, and most importantly, the URL of the generated manifest file.

The client downloads the manifest before requesting any video content.

The manifest informs the player about every available quality level and provides the location of every segment belonging to each quality.

The player estimates the user's available bandwidth and selects an initial quality.

Instead of downloading the complete video, the player requests only the first segment from the CDN.

While the first segment is being played, subsequent segments are downloaded in the background.

After each segment finishes downloading, the player measures:

• Current throughput
• Buffer size
• Download latency
• Playback performance

If bandwidth improves, the next segment can be requested at a higher quality.

If bandwidth decreases, the next segment is requested using a lower bitrate.

Because switching occurs only between segment boundaries, playback continues smoothly without restarting the video.

This mechanism is known as Adaptive Bitrate Streaming (ABR) and is the standard approach used by modern streaming platforms.

CDN Distribution

Serving every video request directly from blob storage would generate enormous bandwidth costs and introduce high latency for users located far from the storage region.

Instead, transcoded segments are distributed through a Content Delivery Network.

CDN edge servers cache video segments close to users around the world.

When a segment is requested:

• If the segment already exists at the edge, it is returned immediately.
• Otherwise, the CDN retrieves it from origin storage, caches it, and serves it to the client.

Since each segment is only a few seconds long, only the requested portions of the video are transferred instead of the entire file.

The CDN therefore handles the overwhelming majority of read traffic, while origin storage primarily acts as the durable source of truth.

Hybrid CDN Strategy

Caching every uploaded video inside the CDN would be prohibitively expensive because the majority of uploaded content receives very few views.

Instead, the architecture follows a hybrid caching strategy.

Highly popular videos remain cached in CDN edge locations to provide extremely low latency and reduce origin traffic.

Less frequently viewed videos are streamed directly from blob storage whenever necessary.

As popularity changes over time, videos naturally migrate between origin storage and CDN caches according to demand.

This balances infrastructure cost with user experience.

Scalability Characteristics

The architecture is designed so that every major component can scale independently.

The API layer remains completely stateless, allowing additional instances to be added behind a load balancer whenever request volume increases.

Blob storage provides virtually unlimited storage capacity for raw uploads and transcoded outputs.

The queue absorbs upload spikes by buffering processing requests.

The DAG-based transcoding system scales horizontally by simply adding more worker nodes.

Metadata storage scales through partitioning across database nodes.

Redis reduces repeated database queries for popular content.

The CDN absorbs nearly all streaming traffic, preventing backend services from becoming bandwidth bottlenecks.

Since upload, processing, metadata management, and streaming are loosely coupled through asynchronous communication and object storage, failures in one subsystem rarely impact the others. The resulting architecture achieves high availability, efficient resource utilization, and the ability to support millions of concurrent uploads and streams while maintaining low latency and predictable operational costs.