Video Streaming System Design (HLD & LLD)

A video streaming platform (such as YouTube, Netflix, or Amazon Prime Video) is a common system design interview topic. This document covers the architecture, components, APIs, data model, scalability considerations, and the role of metadata in video transcoding.

Functional Requirements

Core Features

Upload videos
Process and transcode videos
Store videos
Stream videos
Search videos
Like, comment, and share
Personalized recommendations

Non-Functional Requirements

High scalability
Low-latency playback
Fault tolerance
Global availability
Cost-efficient storage
Adaptive bitrate streaming

High-Level Architecture

flowchart TD
    C[Client] --> G[API Gateway]
    G --> VS[Video Service]
    G --> MS[Metadata Service]
    G --> US[User Service]
    G --> RS[Recommendation Service]

    VS --> S3[Object Storage]
    VS --> Q[Message Queue]

    Q --> ENC[Encoding Service]
    ENC --> S3

    MS --> DB[(Metadata DB)]
    US --> UDB[(User DB)]
    RS --> ML[ML Models]

    S3 --> CDN[CDN]
    CDN --> Viewer[End User]

Core Components

API Gateway

Responsibilities:

Authentication
Rate limiting
Request routing

Video Upload Service

Flow:

Client -> Upload Service -> Object Storage -> Queue -> Encoder

Responsibilities:

Accept uploads
Store original video
Trigger asynchronous encoding

Encoding Service

The uploaded video is transcoded into multiple resolutions.

Example outputs:

240p
360p
480p
720p
1080p

Typical output files:

video_240p.mp4
video_360p.mp4
video_720p.mp4

Storage

Object Storage:

Original videos
Encoded videos
HLS/DASH segments

Metadata Database:

video_id
title
description
duration
owner_id
upload_time
views

CDN

Benefits:

Edge caching
Reduced latency
Lower origin load

Streaming Protocols

Adaptive Bitrate Streaming using:

HLS
MPEG-DASH

Video is split into segments:

segment1.ts
segment2.ts
segment3.ts

The player automatically switches quality depending on network conditions.

Upload Flow

flowchart LR
    U[User Upload] --> S[Object Storage]
    S --> M[Metadata Extractor]
    M --> Q[Queue]
    Q --> E[Encoding Service]
    E --> P[HLS/DASH Packager]
    P --> O[Store Encoded Variants]
    O --> CDN

Steps:

User uploads video.
API Gateway authenticates the request.
Video is stored in object storage.
Upload event is sent to a queue.
Encoding service generates multiple resolutions.
Metadata is stored.
CDN caches content.
Users stream the video.

Streaming Flow

sequenceDiagram
    participant User
    participant CDN
    participant Origin

    User->>CDN: Request master.m3u8
    alt Cache Hit
        CDN-->>User: Playlist
    else Cache Miss
        CDN->>Origin: Fetch playlist/segments
        Origin-->>CDN: Response
        CDN-->>User: Playlist/segments
    end

Player downloads:

master.m3u8
chunk1.ts
chunk2.ts
chunk3.ts

Database Design

Video Table

Video
------
video_id (PK)
user_id
title
description
duration
upload_time
views
status

VideoFiles Table

VideoFiles
----------
file_id
video_id
resolution
url
size
format

Users Table

Users
-----
user_id
name
email
created_at

Comments Table

Comments
--------
comment_id
video_id
user_id
text
created_at

API Design

Upload Video

POST /videos

Request:

{
  "title": "System Design",
  "description": "Video streaming architecture"
}

Get Metadata

GET /videos/{id}

Get Streaming URL

GET /videos/{id}/stream

Response:

{
  "stream_url": "cdn.com/video123/master.m3u8"
}

Like Video

POST /videos/{id}/like

Low-Level Design

Video Entity

class Video {
    String videoId;
    String title;
    String description;
    String userId;
    long duration;
    long views;
}

Video Service

class VideoService {

    VideoRepository repository;

    public Video upload(VideoUploadRequest req) {
        Video video = new Video();
        video.setTitle(req.getTitle());
        video.setDescription(req.getDescription());

        repository.save(video);
        return video;
    }
}

Streaming Service

class StreamingService {

    public String getStreamingUrl(String videoId) {
        return cdnService.getPlaylist(videoId);
    }
}

Scalability Considerations

Challenge	Solution
Storage explosion	Compression and object storage
Upload spikes	Pre-signed uploads
Hot videos	CDN edge caching
CPU-intensive encoding	Distributed worker queues
Metadata lookups	Redis caching

Additional optimizations:

Kafka/RabbitMQ for asynchronous processing
Redis for metadata and counters
Elasticsearch for search
Batch updates for view counts

Advanced Topics

Live Streaming

Pipeline:

RTMP Ingest -> Encoder -> HLS/DASH Packaging -> CDN

Recommendation System

Inputs:

Watch history
Clicks
Watch duration

View Counting

Use Redis counters and periodically flush aggregated counts to the database.

Role of Metadata in Resolution Generation

Video metadata is only partially responsible for preparing different resolutions.

1. Source Video Metadata (Used by the Encoder)

Technical metadata extracted from the uploaded file:

{
  "width": 3840,
  "height": 2160,
  "duration": 3600,
  "bitrate": 25000000,
  "codec": "h264",
  "fps": 30
}

This metadata determines:

Supported output resolutions
Bitrate ladder
Codec compatibility
Whether transcoding is required

Example:

Source Resolution	Generated Variants
4K	2160p, 1440p, 1080p, 720p, 480p
1080p	1080p, 720p, 480p, 360p
720p	720p, 480p, 360p
480p	480p, 360p

A 720p source cannot produce a true 1080p stream.

2. Application Metadata (Not Used for Transcoding)

Typical application metadata:

{
  "videoId": "123",
  "title": "System Design Tutorial",
  "description": "Video Streaming Architecture",
  "uploadedBy": "user1",
  "views": 1000
}

Used for:

Search
Recommendations
UI display
Analytics
User feeds

Encoding Decision Flow

flowchart TD
    U[Video Upload] --> O[Object Storage]
    O --> X[Metadata Extractor]
    X -->|Resolution Codec FPS| E[Encoding Service]
    E --> R1[1080p]
    E --> R2[720p]
    E --> R3[480p]
    E --> R4[360p]
    R1 --> P[HLS/DASH Packager]
    R2 --> P
    R3 --> P
    R4 --> P

Example metadata table:

VideoMetadata
-------------
video_id
source_width
source_height
duration
fps
codec
bitrate
aspect_ratio
status

The encoding service reads these fields to choose encoding profiles and generate adaptive streaming variants.

Interview Answer

When asked how resolutions are generated:

After upload, the system extracts technical metadata such as resolution, bitrate, codec, and frame rate from the source video. Based on predefined encoding profiles, the transcoding service generates multiple resolution variants (1080p, 720p, 480p, etc.). These variants are segmented and packaged into HLS/DASH manifests to support adaptive bitrate streaming.

Key Takeaways

Separate application metadata from technical media metadata.
Technical metadata drives transcoding decisions.
Adaptive streaming relies on multiple encoded variants and segmented media.
Asynchronous encoding, object storage, CDN, and caching are fundamental to scalability.
HLS/DASH packaging enables seamless quality switching during playback.