🎬 Netflix System Design — Interview Class Notes

This transcript focuses mainly on three major flows:

Video Upload
Video Streaming
Video Search

The most important architectural idea is:

Separate the upload/processing pipeline from the streaming/read path, and use Object Storage + CDN to serve huge video files efficiently.

1. Problem Statement

Design a Netflix-like video streaming platform that supports:

Admin video upload
Video processing/transcoding
Thumbnail generation
Persistent video storage
Video streaming
Search
Metadata management
Global low-latency delivery

The key challenge is:

Large video files require expensive processing during upload, but millions of users need fast, reliable streaming afterward.

2. Three Core Assumptions ⭐

① Read-heavy or Write-heavy?

Extremely Read-heavy

Netflix has relatively few content uploads compared with the enormous number of video viewing requests.

Content creators/admins
        ↓
     Uploads
        ↓
   relatively few

Users
        ↓
     Streaming
        ↓
   millions/billions

Therefore:

Netflix is extremely read-heavy.

3. Distributed or Single Server?

Distributed system

We need:

Multiple API instances
Processing workers
Message queues
Object storage
CDN
Search infrastructure
Databases
Multiple geographic regions

Users
  ↓
Load Balancer
  ↓
Multiple Services
  ↓
Distributed Infrastructure

4. Consistency or Availability?

⭐ Availability

For a streaming platform, availability is extremely important.

If:

Netflix unavailable
      ↓
User cannot watch
      ↓
Bad experience

Some metadata/search information can tolerate eventual consistency.

For example:

New movie uploaded
      ↓
Metadata indexed
      ↓
Search becomes available shortly later

That's generally acceptable.

But:

The uploaded video itself must not be lost or corrupted.

So distinguish availability from durability/reliability.

5. Functional Requirements

Core Requirements

1. Video Upload

Admin should be able to upload:

Video
Metadata
User/admin ID

Admin
  ↓
Upload Service

2. Video Processing

Uploaded video needs processing before streaming.

Examples:

Transcoding
Compression
Resolution conversion
Format conversion
Chunk processing

3. Thumbnail Generation

Generate thumbnails during processing.

Video
 ↓
Processing
 ↓
Thumbnail
 ↓
Object Storage

4. Video Streaming ⭐⭐⭐

Users should be able to:

Search
 ↓
Select video
 ↓
Stream video

Supported clients could include:

Web
Mobile
Smart TV
Other streaming devices

5. Search

Users should be able to search by:

Title
Description
Genre
Other metadata

User
 ↓
Search Service
 ↓
Search Engine
 ↓
Results

6. Non-Functional Requirements

① High Availability ⭐⭐⭐

Users expect the service to be available continuously.

② Low Latency

Video should start playing quickly.

Important metric:

Time to First Byte / Time to First Frame

The user shouldn't wait a long time after pressing Play.

③ Smooth Streaming ⭐⭐⭐

Once playback starts:

Video
████████████████████

should continue without:

Video
███
   ⏸ Buffering
       ███
          ⏸

④ Scalability

Must support:

Normal traffic
      ↓
Peak traffic
      ↓
Millions of concurrent viewers

⑤ Reliability / Durability

Uploaded content must not disappear.

Need:

Replication
Durable object storage
Backup
Disaster recovery

7. High-Level Architecture ⭐⭐⭐

Start with this diagram.

                         ADMIN
                           │
                           ▼
                    ┌─────────────┐
                    │Load Balancer│
                    └──────┬──────┘
                           │
                           ▼
                    Upload Service
                           │
                           ▼
                      Message Queue
                           │
                    ┌──────┴──────┐
                    ▼             ▼
               Worker 1       Worker 2
                    │             │
                    └──────┬──────┘
                           ▼
                    Object Storage
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
          Video         Thumbnail      Metadata

Then streaming:

                         USER
                           │
                           ▼
                    ┌─────────────┐
                    │Load Balancer│
                    └──────┬──────┘
                           │
                           ▼
                     Video Service
                           │
                           ▼
                          CDN
                           │
                           ▼
                    Object Storage

And search:

                         USER
                           │
                           ▼
                     Search Service
                           │
                           ▼
                    Search Engine

8. Video Upload Flow ⭐⭐⭐

Let's go step-by-step.

Step 1 — Admin Uploads Video

Admin
 ↓
Load Balancer
 ↓
Upload Service

Request contains:

video file
metadata
admin/user ID

9. Why Load Balancer?

There may be multiple upload service instances.

                 Load Balancer
                 /     |     \
                /      |      \
               ▼       ▼       ▼
           Upload    Upload   Upload
           Server    Server   Server

This provides:

Horizontal scalability
Fault tolerance
Better throughput

10. The Important Design Decision — Where Does the Uploaded Data Go?

There are two approaches.

Option A — Object Storage First

Upload
 ↓
Object Storage
 ↓
Processing

Advantages:

Durable
Upload can resume
Processing can happen later
Better separation

Option B — Queue Chunks Directly

The transcript chooses this approach.

Upload Service
      ↓
50 MB chunks
      ↓
Message Queue
      ↓
Processing Workers

Why?

Because the queue decouples:

Upload

from:

Processing

11. Why 50 MB Chunks? ⭐

Large video files should not necessarily be processed as one giant request.

Split:

Video
 ↓
Chunk 1 = 50 MB
Chunk 2 = 50 MB
Chunk 3 = 50 MB
Chunk 4 = 50 MB

Then:

Chunk 1 → Worker A
Chunk 2 → Worker B
Chunk 3 → Worker C
Chunk 4 → Worker D

This allows parallel processing.

12. Queue Provides Backpressure ⭐⭐⭐

Suppose:

Upload traffic
= 1,000 chunks/sec

but processing capacity is:

500 chunks/sec

Without a queue:

Workers overwhelmed ❌

With a queue:

Upload
 ↓
Queue
 ↓
500 chunks/sec processed

The remaining chunks wait.

This is called:

Backpressure / workload buffering

13. Worker Service

Workers perform computationally expensive operations.

Queue
  │
  ├── Worker 1
  ├── Worker 2
  ├── Worker 3
  └── Worker 4

Workers can scale horizontally.

High workload
     ↓
More workers

This is much better than making the Upload Service perform heavy processing synchronously.

14. Why Asynchronous Processing? ⭐⭐⭐

Bad architecture:

Admin
 ↓
Upload API
 ↓
Transcode video
 ↓
Generate thumbnail
 ↓
Store video
 ↓
Response

The request may take a very long time.

Better:

Admin
 ↓
Upload Service
 ↓
Queue
 ↓
Return accepted

Then:

Queue
 ↓
Workers
 ↓
Process asynchronously

This keeps the API responsive.

15. Processed Video → Object Storage

After processing:

Worker
 ↓
Processed Video
 ↓
Object Storage

Object storage is ideal for huge binary files.

Examples conceptually:

videos/
 ├── movie123/
 │    ├── chunk001
 │    ├── chunk002
 │    ├── chunk003
 │    └── ...

16. Thumbnail Generation

During processing:

Video Chunk
    ↓
Worker
    ├── Process Video
    │
    └── Generate Thumbnail

Then:

Thumbnail
 ↓
Object Storage

Metadata stores a reference:

video_id
thumbnail_url/reference

17. Video Processing Pipeline ⭐

The complete pipeline:

                    ADMIN
                      │
                      ▼
                Upload Service
                      │
                      ▼
                   Queue
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
       Worker       Worker       Worker
          │           │           │
          └───────────┼───────────┘
                      ▼
                Processed Video
                      │
                      ▼
                Object Storage
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
     Thumbnails              Metadata

18. Streaming Architecture ⭐⭐⭐⭐⭐

Now switch perspective.

We're no longer thinking about admins.

We're thinking about:

Millions of users watching videos.

User
 ↓
Video Service
 ↓
CDN
 ↓
Video Content

19. Why CDN Is the Most Important Component? ⭐⭐⭐⭐⭐

Suppose the video is stored in:

US Data Center

and the user is in:

India

If every video byte travels:

India → US → India

latency and bandwidth costs increase.

Instead:

                 Origin
             Object Storage
                   │
                   ▼
                  CDN
             /      |      \
            /       |       \
           ▼        ▼        ▼
         India     Europe    US
           │
           ▼
         User

The CDN caches content geographically closer to users.

20. CDN Cache Flow

First request:

User
 ↓
CDN
 ↓
Cache MISS
 ↓
Object Storage
 ↓
CDN
 ↓
User

Next requests:

User
 ↓
CDN
 ↓
Cache HIT
 ↓
User

No need to repeatedly access the origin.

21. Why This Is Critical for Netflix

Suppose:

Movie X

becomes extremely popular.

Millions of users request it.

Without CDN:

Millions
   ↓
Object Storage
   ↓
🔥 Huge load

With CDN:

Millions
   ↓
CDN Edge
   ↓
Cached Movie

This dramatically reduces origin load.

22. Streaming Chunks

Don't think of streaming as:

Download entire 10 GB movie
       ↓
Start watching

Instead:

Video
 ↓
Segments
 ↓
Segment 1
Segment 2
Segment 3
Segment 4
...

The player downloads segments progressively.

This enables:

Faster startup
Seeking
Adaptive bitrate
Better failure recovery

23. Adaptive Bitrate Streaming ⭐⭐⭐

A strong extension to mention in an interview.

Create multiple versions:

Movie
 ├── 4K
 ├── 1080p
 ├── 720p
 └── 480p

Client chooses based on network conditions.

Example:

Good network
 ↓
1080p

Poor network
 ↓
480p

This prevents excessive buffering.

24. Search Architecture ⭐⭐⭐

The transcript introduces:

Search Service
       ↓
Search Engine

For example:

User
 ↓
Search Service
 ↓
Search Engine
 ↓
Results

25. How Does Search Engine Get Data?

Important!

When video is uploaded:

Upload
 ↓
Processing
 ↓
Metadata
 ↓
Search Index

So:

Video Metadata
      ↓
Search Indexer
      ↓
Search Engine

26. Search Index Is a Derived Data Store

This is an important interview concept.

Your primary metadata DB might contain:

video_id
title
description
genre
release_date
thumbnail

Search engine contains a searchable representation.

Metadata DB
     │
     ▼
Indexer
     │
     ▼
Search Engine

Therefore:

Search engine is generally not the source of truth.

27. Search Event Architecture

A scalable approach:

Upload / Metadata Service
          │
          ▼
        Kafka
          │
          ▼
     Search Indexer
          │
          ▼
     Search Engine

This avoids making upload dependent on synchronous search indexing.

28. Database Architecture

Possible storage:

Metadata

Metadata DB

Contains:

video_id
title
description
genre
thumbnail_reference
status

Video

Object Storage

Search

Elasticsearch/OpenSearch-like engine

Processing

Message Queue / Kafka

CDN

Edge Cache

29. Video Processing State Machine

Very useful design.

UPLOADED
   ↓
PROCESSING
   ↓
PROCESSED
   ↓
AVAILABLE

Failure:

PROCESSING
    ↓
FAILED
    ↓
RETRY

This prevents the system from accidentally serving incomplete videos.

30. Failure Handling ⭐⭐⭐

Suppose Worker 2 crashes.

Queue
 ↓
Worker 2 💥

Message should become available for retry.

Queue
 ↓
Worker 3
 ↓
Process

Use:

Retries
Exponential backoff
Dead-letter queue
Idempotent processing

31. Idempotency

Suppose:

Chunk 10
 ↓
Worker
 ↓
Processing successful
 ↓
Worker crashes before ACK

Queue retries.

Now the same chunk gets processed again.

If processing isn't idempotent:

Duplicate output ❌

Use a unique identifier:

video_id + chunk_id + processing_version

Then the worker can safely detect:

"This chunk has already been processed."

32. Upload Reliability

The transcript chooses:

Upload → Queue

But in a real interview, mention the alternative:

Object Storage First

Client
 ↓
Object Storage
 ↓
Queue/Event
 ↓
Workers

This can be more robust for very large uploads because object storage provides durable persistence and can support resumable/multipart uploads.

Interview answer:

"Both are valid. For the simplified design I'll follow the transcript and put chunks into a durable queue, but for a production-scale implementation I'd strongly consider direct multipart upload to object storage followed by an event-driven processing pipeline."

That's a very good trade-off discussion.

33. Netflix Architecture — Complete ⭐⭐⭐⭐⭐

                              ADMIN
                                │
                                ▼
                         Load Balancer
                                │
                                ▼
                         Upload Service
                                │
                                ▼
                         Message Queue
                                │
                 ┌──────────────┼──────────────┐
                 ▼              ▼              ▼
              Worker          Worker          Worker
                 │              │              │
                 └──────────────┼──────────────┘
                                │
                    ┌───────────┴───────────┐
                    ▼                       ▼
              Video Storage           Thumbnail Storage
                    │
                    ▼
               CDN / Origin
                    ▲
                    │
              Video Service
                    ▲
                    │
                    │
                  USER
                    │
             Web / Mobile / TV


             Metadata Pipeline
                    │
                    ▼
              Metadata DB
                    │
                    ▼
                  Kafka
                    │
                    ▼
              Search Indexer
                    │
                    ▼
             Search Engine
                    ▲
                    │
              Search Service
                    ▲
                    │
                  USER

34. Netflix vs Spotify ⭐

Since you've already studied Spotify, this comparison is useful.

Concept	Spotify	Netflix
Media	Audio	Video
Workload	Read-heavy	Extremely read-heavy
Upload	Audio	Video
Processing	Audio processing	Heavy video transcoding
CDN	⭐⭐⭐	⭐⭐⭐⭐⭐
Object Storage	⭐⭐⭐	⭐⭐⭐⭐⭐
Search	Search engine	Search engine
Queue	Processing	Processing/transcoding
Main challenge	Audio streaming	Video streaming + transcoding
Adaptive bitrate	Important	Very important
Thumbnail	Album/artwork	Video thumbnails
Main bottleneck	Bandwidth	Bandwidth + processing

35. Most Important Interview Deep Dive

If interviewer asks:

"What's the hardest part of Netflix?"

Answer:

Video processing + global video delivery

The pipeline is:

Upload
 ↓
Chunk
 ↓
Queue
 ↓
Workers
 ↓
Transcode
 ↓
Multiple resolutions
 ↓
Object Storage
 ↓
CDN
 ↓
Millions of Users

36. 30-Second Interview Answer ⭐⭐⭐

"I would design Netflix as an extremely read-heavy distributed streaming system. For video ingestion, admins upload content through an Upload Service behind a load balancer. Large files are split into chunks and processed asynchronously through a durable queue, allowing multiple worker instances to perform computationally expensive transcoding and thumbnail generation in parallel. Processed video and thumbnails are stored in durable object storage. For playback, users access a Video Service, but the actual media delivery should happen primarily through a geographically distributed CDN to minimize latency and protect the origin from massive traffic. I'd store video metadata separately and index searchable fields asynchronously into a search engine. For reliability, I'd use replication, retries, idempotent processing and durable storage. For smooth playback, I'd support segmented adaptive-bitrate streaming with multiple resolutions."

🧠 37. Netflix — Memorize This Architecture

                NETFLIX
                   │
       ┌───────────┼────────────┐
       ▼           ▼            ▼
     Upload      Process       Search
       │           │            │
       ▼           ▼            ▼
    Queue       Workers      Search Engine
                   │
                   ▼
             Object Storage
                   │
                   ▼
                  CDN
                   │
                   ▼
                 Users

🔥 One-line memory trick

Netflix = Upload → Queue → Transcode → Object Storage → CDN → Stream

And the four concepts you absolutely should know for an interview:

Async video processing
Object storage for large media
CDN for global streaming
Search index as a derived data store

Your four-system pattern is now becoming clear:

System	Core interview problem
Spotify	Audio streaming
Amazon	Inventory + payment consistency
WhatsApp	Real-time messaging + ordering
Twitter	Fan-out + timeline generation
Netflix	Video processing + CDN streaming

This is the right way to study these mock interviews: don't memorize every component—memorize the unique bottleneck and the architectural decision that solves it.

Saturday, 29 August 2026

Netflix System Design - Upload → Queue → Transcode → Object Storage → CDN → Stream

🎬 Netflix System Design — Interview Class Notes

1. Problem Statement

2. Three Core Assumptions ⭐

① Read-heavy or Write-heavy?

Extremely Read-heavy

3. Distributed or Single Server?

Distributed system

4. Consistency or Availability?

⭐ Availability

5. Functional Requirements

Core Requirements

1. Video Upload

2. Video Processing

3. Thumbnail Generation

4. Video Streaming ⭐⭐⭐

5. Search

6. Non-Functional Requirements

① High Availability ⭐⭐⭐

② Low Latency

③ Smooth Streaming ⭐⭐⭐

④ Scalability

⑤ Reliability / Durability

7. High-Level Architecture ⭐⭐⭐

8. Video Upload Flow ⭐⭐⭐

Step 1 — Admin Uploads Video

9. Why Load Balancer?

10. The Important Design Decision — Where Does the Uploaded Data Go?

Option A — Object Storage First

Option B — Queue Chunks Directly

11. Why 50 MB Chunks? ⭐

12. Queue Provides Backpressure ⭐⭐⭐

13. Worker Service

14. Why Asynchronous Processing? ⭐⭐⭐

15. Processed Video → Object Storage

16. Thumbnail Generation

17. Video Processing Pipeline ⭐

18. Streaming Architecture ⭐⭐⭐⭐⭐

19. Why CDN Is the Most Important Component? ⭐⭐⭐⭐⭐

20. CDN Cache Flow

21. Why This Is Critical for Netflix

22. Streaming Chunks

23. Adaptive Bitrate Streaming ⭐⭐⭐

24. Search Architecture ⭐⭐⭐

25. How Does Search Engine Get Data?

26. Search Index Is a Derived Data Store

27. Search Event Architecture

28. Database Architecture

Metadata

Video

Search

Processing

CDN

29. Video Processing State Machine

30. Failure Handling ⭐⭐⭐

31. Idempotency

32. Upload Reliability

Object Storage First

Interview answer:

33. Netflix Architecture — Complete ⭐⭐⭐⭐⭐

34. Netflix vs Spotify ⭐

35. Most Important Interview Deep Dive

Video processing + global video delivery

36. 30-Second Interview Answer ⭐⭐⭐

🧠 37. Netflix — Memorize This Architecture

🔥 One-line memory trick

Your four-system pattern is now becoming clear:

No comments:

Post a Comment