Design YouTube

02 Aug 2026, Updated: 10 Aug 2026 14 min read
1
A YouTube is a video-sharing platform where users upload, watch, search, and stream videos.

The system should support billions of videos, millions of concurrent viewers, adaptive video streaming, and low-latency content delivery.

Requirements

Functional Requirements

The YouTube system should satisfy the following functional requirements.

1. Allow users to upload videos.
2. Allow users to watch videos.
3. Allow users to search for videos.
4. Allow users to like and comment on videos.
5. Allow users to subscribe to channels.
6. Support multiple video resolutions.
7. Provide personalized video recommendations.
8. Track video views.
9. Send notifications for subscribed channels.

Non-Functional Requirements

The system should also satisfy the following non-functional requirements.

1. Low latency.
2. High availability.
3. Horizontal scalability.
4. High throughput.
5. Fault tolerance.
6. Low-latency global video delivery.

Capacity Estimation

The following estimation uses reasonable assumptions for a large-scale video-sharing platform.

1. Daily Active Users

Assume the platform has approximately 100 million Daily Active Users (DAU). If each active user watches approximately 5 videos per day, the system would handle: 
Daily Video Views
= 100 million users × 5 videos
= 500 million video views/day
Therefore, the platform may need to support approximately 500 million video playback sessions per day.

Assuming users spend an average of 30 minutes per day watching videos, the platform would need to continuously serve a very large amount of video content through the CDN.

2. Monthly Active Users

Assume approximately 500 million Monthly Active Users (MAU). The relationship between DAU and MAU can be estimated as: 
DAU = 100 million
MAU = 500 million

DAU / MAU = 20%
This means approximately 20% of monthly active users may use the platform on a typical day.

The MAU number is important for estimating persistent user data such as profiles, subscriptions, watch history, preferences, recommendations, and other user-related metadata.

3. Throughput – Read & Write

The platform is heavily read-dominant because users watch and search for videos far more frequently than they upload videos.

Read Throughput

Assume 500 million video views per day. 
Video Views per Day = 500 million

Average Video Playback Requests
= 500 million / 86,400
≈ 5,800 requests/second
During peak traffic, the system may experience approximately 5–10× the average traffic. 
Peak Playback Requests
≈ 30,000 – 60,000 requests/second
In addition to playback requests, users generate requests for video metadata, search, recommendations, channels, comments, likes, and other application APIs.

If each video view results in approximately 10 read operations across these services: 
Daily Reads
= 500 million × 10
= 5 billion reads/day

Average Read Throughput
= 5 billion / 86,400
≈ 58,000 reads/second
At peak traffic, the platform may therefore need to support approximately 300,000–600,000 read operations per second across its application services.

Write Throughput

Writes include video uploads, likes, comments, subscriptions, watch events, view events, and other user activity. Assume each active user generates approximately 5 write events per day. 
Daily Write Events
= 100 million × 5
= 500 million writes/day
The average write throughput would therefore be: 
Average Writes/sec
= 500 million / 86,400
≈ 5,800 writes/second
During peak traffic, the system should be designed for approximately 30,000–60,000 write events per second.

These high-volume events should generally be processed asynchronously using Kafka rather than synchronously updating the primary database for every event.

4. Storage / Memory

Video content is the largest storage requirement in the system.

Assume the platform receives approximately 1 million new videos per day. If the average original uploaded video is approximately 1 GB: 
Original Video Storage
= 1 million × 1 GB
= 1 PB/day
The transcoding pipeline generates multiple resolutions and formats. Assume the total storage required for all encoded variants is approximately 3× the original video size. 
Encoded Video Storage
= 1 PB × 3
= 3 PB/day
Therefore: 
Total Video Storage
≈ 4 PB/day
≈ 1.46 EB/year
In a real production system, storage requirements would depend heavily on the average video size, retention policies, codec efficiency, number of resolutions, replication, and deduplication.

Video files should therefore be stored in highly scalable Object Storage rather than relational databases.

Metadata is significantly smaller than video content. For example, if each video requires approximately 10 KB of metadata: 
Metadata per Day
= 1 million × 10 KB
≈ 10 GB/day
The metadata can be stored in a distributed relational or NoSQL data store depending on access patterns.

Memory / Cache

Frequently accessed video metadata, channel information, and recommendation results can be stored in Redis.

Assume approximately 10 million hot objects are cached with an average memory footprint of 10 KB each. 
Cache Memory
= 10 million × 10 KB
≈ 100 GB
With replication, overhead, eviction headroom, and additional cached data, the Redis cluster may require approximately 200–500 GB or more of usable memory depending on the workload.

The actual video content should not normally be stored in Redis. Video segments should be served through the CDN.

5. Network & Bandwidth

Video delivery represents the largest network requirement.

Assume: 
Daily Active Users = 100 million
Average Watching Time = 30 minutes/user/day
Average Streaming Bitrate = 3 Mbps
The approximate daily video bandwidth can be estimated as: 
Daily Video Data
= 100 million × 30 minutes × 3 Mbps

= 100 million × 1,800 seconds × 3 Mbps
≈ 540 petabits/day

≈ 67.5 PB/day
Therefore, the platform may need to deliver approximately 67.5 PB of video data per day under these assumptions.

The average network bandwidth would be approximately: 
Average Bandwidth
≈ 67.5 PB / 86,400 seconds
≈ 6.25 GB/sec
≈ 50 Gbps
However, real systems must be designed for peak traffic rather than average traffic. If peak traffic is approximately 10× the average: 
Peak Bandwidth
≈ 50 Gbps × 10
≈ 500 Gbps
This is why video content cannot be served directly through application servers. The majority of the traffic should be handled by a globally distributed CDN.

The CDN caches frequently accessed video segments at edge locations close to users, significantly reducing traffic to the origin Object Storage and backend services.

API Design

Upload Video

The client first creates a video upload request through the Video Service. The service creates the video metadata record and returns a temporary upload URL.

Request: 
POST /api/v1/videos
Request Body: 
{
  "title": "System Design Explained",
  "description": "System design fundamentals",
  "channelId": "C101"
}
Response: 
{
  "videoId": "V12345",
  "status": "UPLOADING",
  "uploadUrl": "https://storage.example.com/upload/..."
}
The client then uploads the actual video directly to Object Storage using the temporary upload URL.

Watch Video

The client requests video playback metadata using the video ID.

Request: 
GET /api/v1/videos/V12345
Response: 
{
  "videoId": "V12345",
  "title": "System Design Explained",
  "channelId": "C101",
  "duration": 720,
  "status": "READY",
  "streamUrl": "https://cdn.example.com/videos/V12345/manifest.m3u8"
}
The Streaming Service returns the manifest URL. The client then retrieves video segments directly from the CDN.

Search Videos

The Search Service provides video discovery based on titles, descriptions, tags, and channel information.

Request: 
GET /api/v1/search?q=system+design&page=1&limit=20
Response: 
{
  "videos": [
    {
      "videoId": "V12345",
      "title": "System Design Explained",
      "channelId": "C101",
      "channelName": "Tech With Amit"
    }
  ],
  "page": 1,
  "limit": 20,
  "total": 1250
}
The search request is handled by the Search Service, which retrieves results from Elasticsearch.

Like Video

Users can like a video using the following API.

Request: 
POST /api/v1/videos/V12345/like
Response: 
{
  "videoId": "V12345",
  "liked": true,
  "likeCount": 152340
}
The like operation can also generate an event that is published to Kafka for recommendations, analytics, and other downstream processing.

Comment on Video

Users can add comments to videos.

Request: 
POST /api/v1/videos/V12345/comments
Request Body: 
{
  "text": "Great explanation of system design."
}
Response: 
{
  "commentId": "CM1001",
  "videoId": "V12345",
  "userId": "U101",
  "text": "Great explanation of system design.",
  "createdAt": "2026-08-10T10:30:00Z"
}
Comments are stored separately from video metadata and can generate asynchronous events for notifications, analytics, and recommendations.

Subscribe to Channel

Users can subscribe to a channel using the following API.

Request: 
POST /api/v1/channels/C101/subscribe
Response: 
{
  "channelId": "C101",
  "subscribed": true,
  "subscriberCount": 152341
}
The subscription can generate an event through Kafka for recommendation and notification processing.

Get Video Resolutions

A video can be available in multiple resolutions such as 240p, 360p, 480p, 720p, 1080p, and 4K.

Request: 
GET /api/v1/videos/V12345/streams
Response: 
{
  "videoId": "V12345",
  "manifestUrl": "https://cdn.example.com/videos/V12345/manifest.m3u8",
  "streams": [
    {
      "resolution": "360p",
      "bitrate": 800
    },
    {
      "resolution": "720p",
      "bitrate": 2500
    },
    {
      "resolution": "1080p",
      "bitrate": 5000
    },
    {
      "resolution": "4K",
      "bitrate": 15000
    }
  ]
}

Get Personalized Recommendations

The Recommendation Service provides personalized videos based on user activity such as watch history, likes, subscriptions, and trending content.

Request: 
GET /api/v1/users/U101/recommendations?page=1&limit=20
Response: 
{
  "videos": [
    {
      "videoId": "V12345",
      "title": "System Design Explained",
      "channelId": "C101",
      "score": 0.97
    },
    {
      "videoId": "V45678",
      "title": "Kafka Deep Dive",
      "channelId": "C205",
      "score": 0.91
    }
  ]
}

Record Video View

A video view should not synchronously update the primary video record for every viewer. Instead, the view can be recorded as an event.

Request: 
POST /api/v1/videos/V12345/views
Request Body: 
{
  "watchDuration": 245,
  "sessionId": "S98765"
}
Response: 
{
  "videoId": "V12345",
  "recorded": true
}
The View Service publishes the event to Kafka. Analytics and view-counting consumers process these events asynchronously.

High-Level Architecture

The following diagram illustrates the high-level architecture of a YouTube-like video-sharing platform.

The API Gateway provides a single entry point for client requests and handles authentication, authorization, rate limiting, request validation, and routing.

Core Services

User Service

The User Service manages users, channels, authentication information, subscriptions, and user-related data.
User
USERS
--------------------------------------------------------------------------------
user_id | username | email              | status  | created_at
--------------------------------------------------------------------------------
U101    | amit     | amit@example.com    | ACTIVE  | 2026-01-10
U205    | rahul    | rahul@example.com   | ACTIVE  | 2026-02-15
Authentication
USER_AUTH
--------------------------------------------------------------------------------
auth_id | user_id | auth_provider | provider_user_id | password_hash | created_at
--------------------------------------------------------------------------------
A1001   | U101    | LOCAL         | NULL             | HASH_...      | 2026-01-10
A1002   | U205    | GOOGLE        | G123456          | NULL          | 2026-02-15
A1003   | U310    | LOCAL         | NULL             | HASH_...      | 2026-03-21
Channel
CHANNEL
--------------------------------------------------------------------------------
channel_id | user_id | name              | description       | status | created_at
--------------------------------------------------------------------------------
C101       | U101    | Tech With Amit    | Technology videos | ACTIVE | 2026-01-12
C205       | U205    | System Design     | System design     | ACTIVE | 2026-02-20
Subscription
SUBSCRIPTION
---------------------------------------------------------------------------
user_id | channel_id | status  | subscribed_at
---------------------------------------------------------------------------
U101    | C205       | ACTIVE  | 2026-04-01
U101    | C310       | ACTIVE  | 2026-04-05

Video Service

The Video Service manages video metadata and the video lifecycle.

It creates video records, generates temporary upload credentials, tracks processing status, stores references to video objects, and exposes video metadata and playback information.

The actual video files are stored in Object Storage. The relational database stores only metadata and references to those objects.
Video
VIDEO
------------------------------------------------------------------------------------------------
video_id | channel_id | title                | description | duration | status      | upload_time
------------------------------------------------------------------------------------------------
V101     | C101       | System Design Basics | ...         | 720      | READY       | 10:00
V102     | C205       | Kafka Deep Dive      | ...         | 960      | READY       | 10:15
V103     | C310       | Java Concurrency     | ...         | 840      | PROCESSING  | 10:30
Video Asset
VIDEO_ASSET
------------------------------------------------------------------------------------------------
asset_id | video_id | resolution | codec | bitrate | object_key                         | status
------------------------------------------------------------------------------------------------
A1001    | V101     | 360p       | H264  | 800     | videos/V101/360p/video.m3u8       | READY
A1002    | V101     | 720p       | H264  | 2500    | videos/V101/720p/video.m3u8       | READY
A1003    | V101     | 1080p      | H264  | 5000    | videos/V101/1080p/video.m3u8      | READY
A1004    | V101     | 4K         | H265  | 15000   | videos/V101/4k/video.m3u8         | READY

Transcoding Service

The Transcoding Service processes uploaded videos asynchronously.

It consumes upload events from Kafka, converts the original video into multiple resolutions and formats, generates thumbnails, and stores the resulting files in Object Storage.
Transcoding Job
TRANSCODING_JOB
------------------------------------------------------------------------------------------------
job_id  | video_id | input_object_key             | status      | retry_count | created_at
------------------------------------------------------------------------------------------------
J1001   | V101     | videos/V101/original.mp4     | COMPLETED   | 0           | 10:02
J1002   | V102     | videos/V102/original.mp4     | COMPLETED   | 1           | 10:17
J1003   | V103     | videos/V103/original.mp4     | PROCESSING  | 0           | 10:32
Transcoding Task
TRANSCODING_TASK
----------------------------------------------------------------------------------------------------
task_id | job_id | video_id | resolution | codec | status      | output_object_key
----------------------------------------------------------------------------------------------------
T1001   | J1001  | V101     | 360p       | H264  | COMPLETED   | videos/V101/360p/video.mp4
T1002   | J1001  | V101     | 720p       | H264  | COMPLETED   | videos/V101/720p/video.mp4
T1003   | J1001  | V101     | 1080p      | H264  | COMPLETED   | videos/V101/1080p/video.mp4
T1004   | J1001  | V101     | 4K         | H265  | PROCESSING  | videos/V101/4k/video.mp4
A single TRANSCODING_JOB belongs to one video and can contain multiple TRANSCODING_TASK records. Each task produces one video variant. Thumbnail generation is tracked separately.

Streaming Service

The Streaming Service manages video playback metadata and returns the appropriate video manifest to the client.

It does not serve video bytes directly. Video segments are stored in Object Storage and delivered to viewers through the CDN.

Video Manifest

VIDEO_MANIFEST
----------------------------------------------------------------------------------------------
manifest_id | video_id | type | object_key                         | status | created_at
----------------------------------------------------------------------------------------------
M1001       | V101     | HLS  | videos/V101/manifest.m3u8          | READY  | 10:20
M1002       | V102     | HLS  | videos/V102/manifest.m3u8          | READY  | 10:35
M1003       | V103     | HLS  | videos/V103/manifest.m3u8          | READY  | 10:50
The object_key references the manifest stored in Object Storage. The Streaming Service can use this information to construct a CDN playback URL.

Video Stream

VIDEO_STREAM
------------------------------------------------------------------------------------------------
stream_id | video_id | resolution | codec | bitrate | object_prefix              | status
------------------------------------------------------------------------------------------------
S1001     | V101     | 360p       | H264  | 800     | videos/V101/360p/          | READY
S1002     | V101     | 720p       | H264  | 2500    | videos/V101/720p/          | READY
S1003     | V101     | 1080p      | H264  | 5000    | videos/V101/1080p/         | READY
S1004     | V101     | 4K         | H265  | 15000   | videos/V101/4k/            | READY
The video player continuously evaluates network bandwidth and playback conditions and switches between available streams.

If bandwidth decreases, the player can switch to a lower resolution to avoid buffering. When bandwidth improves, it can switch back to a higher resolution.

Other Services

The Search Service indexes video metadata such as titles, descriptions, tags, and channel information in Elasticsearch. Search indexing is asynchronous and does not block video uploads.

The Recommendation Service processes watch history, likes, subscriptions, and other activity to generate personalized recommendations. Results can be precomputed and cached in Redis for low-latency retrieval.

The Interaction Service manages likes and comments. These operations are persisted separately from video files and can publish events for downstream processing.

The View and Analytics Service processes video-view events asynchronously.

Instead of synchronously updating the primary database for every view, view events are published to Kafka and processed by view-counting and analytics consumers.

Notification Service consumes events from Kafka and sends notifications when subscribed channels publish new videos or when other notification-generating activities occur.

Non-Functional Requirements

Low Latency

Low latency is achieved by keeping frequently accessed metadata and recommendations in Redis, using Elasticsearch for fast video search, and serving video segments from nearby CDN edge locations.

The application services return playback metadata and manifests, while the CDN handles the actual video delivery.

High Availability

High availability is achieved by running multiple instances of stateless services behind a Load Balancer.

Object Storage, Kafka, Redis, and the relational database use replication and failover mechanisms.

If one service instance or infrastructure component fails, another instance can continue serving requests.

Horizontal Scalability

Application services such as the Video Service, Search Service, Streaming Service, and Recommendation Service are stateless and can be scaled horizontally by adding more instances.

Kafka distributes asynchronous workloads across multiple consumers, while transcoding workers can be increased independently based on video-processing demand.

High Throughput

High throughput is achieved by avoiding synchronous processing for expensive and high-volume operations.

Video transcoding, search indexing, recommendations, view counting, analytics, and notifications are processed asynchronously through Kafka.

This keeps the synchronous API path lightweight and allows each workload to scale independently.

Fault Tolerance

The architecture isolates failures between services. If a transcoding worker fails, the job can be retried. If a Kafka consumer fails, events can be processed again after recovery.

If Elasticsearch is unavailable, video uploads can continue because indexing is asynchronous.

If Redis becomes unavailable, the system can fall back to the underlying database with increased latency.

Global Video Delivery

Global video delivery is achieved through a distributed CDN. Frequently requested video segments are cached at edge locations close to users.

This significantly reduces latency and prevents the application servers and origin storage from handling every video request.

Conclusion

A YouTube-like platform requires scalable storage, processing, and global delivery.

Object Storage stores videos, Kafka handles asynchronous processing, and the CDN delivers video content with low latency.

Redis improves frequently accessed data, while Elasticsearch provides scalable search.

Stateless services, replication, retries, and independent scaling provide high availability, fault tolerance, and high throughput.
← Previous
Design BookMyShow
Next →
Design Cricbuzz
Nagesh Chauhan

Nagesh Chauhan

Principal Software Engineer • Java • Python • Distributed Systems • AI/ML

Principal Software Engineer with 14+ years of experience designing and delivering large-scale distributed systems, cloud-native applications, and AI-powered platforms.

Passionate about solving complex engineering problems using strong data structures and algorithms, along with expertise in Java, Spring Boot, Python, System Design, Microservices, Cloud, Kafka, Elasticsearch, and Generative AI.

Share this Article

💬 Comments

Join the Discussion