চমৎকার। আমি পুরো YouTube System Design অধ্যায়টিকে ৬টি বড় অংশে ভাগ করে ধারাবাহিকভাবে বাংলায় অনুবাদ করব। নিচে Part 1 দিলাম।

ইউটিউব ডিজাইন (Design YouTube)

এই অধ্যায়ে আপনাকে YouTube ডিজাইন করতে বলা হয়েছে। এই সমাধানটি Netflix, Hulu বা অন্য যেকোনো ভিডিও শেয়ারিং/স্ট্রিমিং প্ল্যাটফর্ম ডিজাইনের ক্ষেত্রেও প্রয়োগ করা যেতে পারে।

প্রথম নজরে YouTube খুবই সহজ মনে হয়। কনটেন্ট ক্রিয়েটররা ভিডিও আপলোড করে এবং দর্শকরা ভিডিও চালিয়ে দেখে। কিন্তু বাস্তবে এর পেছনে অসংখ্য জটিল প্রযুক্তি কাজ করে।

চলুন ২০২০ সালের YouTube-এর কিছু চমকপ্রদ পরিসংখ্যান দেখি:

মাসিক সক্রিয় ব্যবহারকারী (MAU): ২ বিলিয়ন
প্রতিদিন দেখা ভিডিও: ৫ বিলিয়ন
যুক্তরাষ্ট্রের ৭৩% প্রাপ্তবয়স্ক YouTube ব্যবহার করে
YouTube-এ কনটেন্ট ক্রিয়েটর: ৫০ মিলিয়ন
২০১৯ সালে বিজ্ঞাপন আয়: ১৫.১ বিলিয়ন ডলার
মোবাইল ইন্টারনেট ট্রাফিকের ৩৭% YouTube-এর কারণে
৮০টিরও বেশি ভাষায় উপলব্ধ

এই পরিসংখ্যান থেকে বোঝা যায়:

YouTube বিশাল আকারের একটি সিস্টেম
এটি বিশ্বব্যাপী ব্যবহৃত হয়
এটি বিপুল পরিমাণ অর্থ উপার্জন করে

ধাপ ১ — সমস্যাটি বোঝা এবং ডিজাইনের পরিধি নির্ধারণ করা

YouTube-এ শুধু ভিডিও দেখা নয়, আরও অনেক ফিচার রয়েছে:

Comment করা
Like/Dislike করা
Share করা
Playlist-এ Save করা
Channel Subscribe করা

একটি ৪৫–৬০ মিনিটের System Design Interview-এ সবকিছু ডিজাইন করা সম্ভব নয়। তাই শুরুতেই Scope নির্ধারণ করা গুরুত্বপূর্ণ।

Interview Question & Answer

Candidate:

কোন ফিচারগুলো সবচেয়ে গুরুত্বপূর্ণ?

Interviewer:

ভিডিও আপলোড করা
ভিডিও দেখা

Candidate:

কোন ধরনের ক্লায়েন্ট সাপোর্ট করতে হবে?

Interviewer:

Mobile App
Web Browser
Smart TV

Candidate:

প্রতিদিন কতজন Active User থাকবে?

Interviewer:

৫ মিলিয়ন

Candidate:

প্রতিদিন একজন ব্যবহারকারী গড়ে কত সময় ব্যয় করে?

Interviewer:

৩০ মিনিট

Candidate:

আন্তর্জাতিক ব্যবহারকারী সাপোর্ট করতে হবে?

Interviewer:

হ্যাঁ, বড় একটি অংশ আন্তর্জাতিক ব্যবহারকারী

Candidate:

কোন ভিডিও রেজোলিউশন সাপোর্ট করতে হবে?

Interviewer:

অধিকাংশ ভিডিও রেজোলিউশন ও ফরম্যাট

Candidate:

Encryption কি প্রয়োজন?

Interviewer:

হ্যাঁ

Candidate:

ভিডিও ফাইলের সাইজ সীমা কত?

Interviewer:

সর্বোচ্চ ১ GB

Candidate:

Amazon, Google অথবা Microsoft-এর Cloud Infrastructure ব্যবহার করা যাবে?

Interviewer:

অবশ্যই। অধিকাংশ কোম্পানির জন্য সবকিছু নিজে তৈরি করা বাস্তবসম্মত নয়। বিদ্যমান Cloud Service ব্যবহার করাই উত্তম।

এই অধ্যায়ে আমরা যে ফিচারগুলো ডিজাইন করব

1. দ্রুত ভিডিও আপলোড

ব্যবহারকারী যেন দ্রুত ভিডিও আপলোড করতে পারে।

2. Smooth Video Streaming

ভিডিও যেন Buffer ছাড়া সুন্দরভাবে চলে।

3. Video Quality পরিবর্তন

প্রয়োজনে 360p, 720p, 1080p ইত্যাদির মধ্যে পরিবর্তন করা যাবে।

4. কম Infrastructure Cost

খরচ যত সম্ভব কম রাখতে হবে।

5. High Availability

সার্ভিস যেন সবসময় সচল থাকে।

6. Scalability

ব্যবহারকারী বাড়লেও সিস্টেম যেন ঠিকভাবে কাজ করে।

7. Reliability

ডেটা হারিয়ে না যায় এবং সিস্টেম নির্ভরযোগ্য হয়।

8. Supported Clients

Mobile App
Web Browser
Smart TV

Back-of-the-Envelope Estimation

এটি একটি প্রাথমিক হিসাব, যা সিস্টেমের আকার বোঝার জন্য করা হয়।

অনুমান

Daily Active User (DAU)

৫ মিলিয়ন

একজন ব্যবহারকারী প্রতিদিন ভিডিও দেখে

৫টি

১০% ব্যবহারকারী প্রতিদিন ভিডিও আপলোড করে

অর্থাৎ:

৫,০০০,০০০ × ১০%

= ৫০০,০০০ ভিডিও প্রতিদিন

গড় ভিডিও সাইজ

৩০০ MB

প্রতিদিন কত Storage লাগবে?

৫০০,০০০ × ৩০০ MB

= ১৫০ TB

অর্থাৎ প্রতিদিন প্রায়:

১৫০ টেরাবাইট নতুন স্টোরেজ

প্রয়োজন হবে।

CDN Cost Estimation

CDN (Content Delivery Network) থেকে ভিডিও পরিবেশন করার সময় Cloud Provider ডেটা ট্রান্সফারের জন্য চার্জ নেয়।

Amazon CloudFront-এর উদাহরণ ধরা যাক।

ধরি:

সব ট্রাফিক USA থেকে আসছে
প্রতি GB খরচ = $0.02

প্রতিদিন ভিডিও স্ট্রিমিং খরচ

৫,০০০,০০০ ব্যবহারকারী

× ৫ ভিডিও

× ০.৩ GB

× $0.02

$150,000 প্রতিদিন

গুরুত্বপূর্ণ পর্যবেক্ষণ

শুধুমাত্র ভিডিও স্ট্রিমিংয়ের CDN খরচই প্রতিদিন প্রায়:

$150,000

যা বছরে দাঁড়ায়:

প্রায় $54.75 Million

এখান থেকেই বোঝা যায়:

ভিডিও স্ট্রিমিং প্ল্যাটফর্মে CDN সবচেয়ে ব্যয়বহুল কম্পোনেন্টগুলোর একটি।

পরবর্তী Deep Dive অংশে আমরা CDN Cost কমানোর বিভিন্ন কৌশল দেখব।

Part 1 শেষ

পরবর্তী Part 2-এ আমি বাংলায় অনুবাদ করব:

Step 2 — High Level Design

Client
CDN
API Server
Video Upload Flow
Video Streaming Flow
Complete System Architecture

যা YouTube-এর পুরো Architecture-এর ভিত্তি তৈরি করে।

Part 2 — High Level Design (উচ্চ-স্তরের ডিজাইন)

আগের অংশে আমরা সমস্যা, Scope এবং প্রাথমিক হিসাব (Estimation) আলোচনা করেছি।

এখন আমরা YouTube-এর High-Level Architecture ডিজাইন করব।

ইন্টারভিউয়ার আগেই পরামর্শ দিয়েছিলেন যে CDN এবং Cloud Storage-এর মতো বিদ্যমান Cloud Service ব্যবহার করা উচিত।

কারণ:

১. System Design Interview-এর উদ্দেশ্য

এখানে সবকিছু নিজে তৈরি করা দেখানো নয়।

বরং সঠিক সমস্যার জন্য সঠিক প্রযুক্তি নির্বাচন করতে পারা গুরুত্বপূর্ণ।

উদাহরণ:

ভিডিও সংরক্ষণের জন্য Blob Storage ব্যবহার করব
ভিডিও ডেলিভারির জন্য CDN ব্যবহার করব

এতটুকু বলাই যথেষ্ট।

২. Blob Storage এবং CDN তৈরি করা অত্যন্ত কঠিন

Netflix, Facebook-এর মতো বড় কোম্পানিও সবকিছু নিজেরা তৈরি করে না।

উদাহরণ:

Netflix → Amazon Cloud ব্যবহার করে
Facebook → Akamai CDN ব্যবহার করে

High-Level Architecture

সম্পূর্ণ সিস্টেমকে ৩টি প্রধান অংশে ভাগ করা যায়।

1. Client

Client বলতে বোঝায়:

Mobile App
Web Browser
Smart TV

ব্যবহারকারীরা এসব ডিভাইসের মাধ্যমে YouTube ব্যবহার করে।

2. CDN (Content Delivery Network)

ভিডিও CDN-এ সংরক্ষিত থাকে।

যখন ব্যবহারকারী Play Button চাপ দেয়,

তখন ভিডিও CDN থেকে সরাসরি Stream হয়।

CDN ব্যবহারের সুবিধা

কম Latency
দ্রুত Video Load
Global Coverage
Server Load কমে

3. API Servers

ভিডিও Streaming ছাড়া বাকি সব Request API Server দিয়ে যায়।

যেমন:

User Signup
Login
Video Upload URL Generate
Recommendation Feed
Like/Comment
Subscription
Metadata Update
Search

Interviewer-এর আগ্রহ

ইন্টারভিউয়ার মূলত দুটি Flow নিয়ে আলোচনা করতে চান।

1. Video Uploading Flow

ভিডিও কীভাবে Upload হয়?

2. Video Streaming Flow

ভিডিও কীভাবে User-এর কাছে পৌঁছায়?

Video Uploading Flow

ভিডিও Upload Architecture-এ নিচের Component গুলো থাকে।

User

ভিডিও Upload করে।

Device হতে পারে:

Mobile
Computer
Smart TV

Load Balancer

সব Request সমানভাবে বিভিন্ন API Server-এ পাঠায়।

কেন দরকার?

যদি একটি API Server-এর উপর সব Load পড়ে:

Server Slow হবে
Crash হতে পারে

তাই Load Balancer Request ভাগ করে দেয়।

API Servers

ভিডিও Streaming বাদে সব Request Handle করে।

Metadata Database

ভিডিও সম্পর্কিত তথ্য সংরক্ষণ করে।

যেমন:

Title
Description
Resolution
Format
Owner
Upload Date

ইত্যাদি।

Performance বাড়াতে

Metadata DB:

Sharding ব্যবহার করে
Replication ব্যবহার করে

Metadata Cache

Metadata বারবার Database থেকে পড়া ব্যয়বহুল।

তাই Frequently Used Data Cache-এ রাখা হয়।

Cache-এ থাকতে পারে

Video Metadata
User Information
Channel Information

Original Storage

এখানে Original Video সংরক্ষণ করা হয়।

এটি সাধারণত Blob Storage হয়।

উদাহরণ:

Amazon S3
Google Cloud Storage
Azure Blob Storage

Blob কী?

BLOB = Binary Large Object

অর্থাৎ বড় Binary Data

যেমন:

Video
Audio
Image

Transcoding Servers

ভিডিও Upload হওয়ার পর Transcoding Server সেটি Process করে।

Transcoding কী?

এক Format থেকে অন্য Format-এ Convert করা।

উদাহরণ:

একটি Video Upload হয়েছে:


video.mov

এখন এটিকে Convert করা হবে:


360p.mp4
480p.mp4
720p.mp4
1080p.mp4

কেন দরকার?

কারণ:

সব Device একই Format Support করে না।

এছাড়া বিভিন্ন Network Speed-এর জন্য বিভিন্ন Resolution দরকার।

Transcoded Storage

Transcoding শেষ হলে নতুন Video File এখানে সংরক্ষণ হয়।

উদাহরণ:


video_360p.mp4
video_720p.mp4
video_1080p.mp4

CDN

Transcoded Video CDN-এ Push করা হয়।

পরবর্তীতে User CDN থেকে Video Stream করে।

Completion Queue

Transcoding শেষ হলে Event Queue-তে একটি Message পাঠানো হয়।

যেমন:


Video #123
Transcoding Completed

Completion Handler

Worker গুলো Queue থেকে Event পড়ে।

তারপর:

Database Update করে
Cache Update করে

Video Upload Flow-এর দুইটি Parallel Process

ভিডিও Upload-এর সময় আসলে দুইটি কাজ একসাথে হয়।

Process A

Actual Video Upload

Process B

Metadata Update

Process A — Actual Video Upload

ধাপগুলো:

Step 1

ভিডিও Original Storage-এ Upload হয়।

Step 2

Transcoding Server Original Video নিয়ে কাজ শুরু করে।

Step 3

Transcoding সম্পন্ন হলে দুইটি কাজ Parallelভাবে হয়।

Step 3A

Transcoded Video

→ Transcoded Storage-এ যায়

Step 3B

Completion Event

→ Completion Queue-তে যায়

Step 3A.1

Transcoded Video

→ CDN-এ Distribute হয়

Step 3B.1

Completion Handler Queue থেকে Event পড়ে।

Step 3B.1.a

Metadata DB Update

Step 3B.1.b

Metadata Cache Update

Step 4

API Server Client-কে জানায়:


ভিডিও সফলভাবে Upload হয়েছে
এবং Streaming-এর জন্য প্রস্তুত।

Process B — Metadata Update

ভিডিও Upload হওয়ার সময় Client আরেকটি Request পাঠায়।

এই Request-এ থাকে:

File Name
File Size
Resolution
Format
User Info

ইত্যাদি।

API Server:

Metadata Cache Update করে

এবং

Metadata Database Update করে

Video Upload Flow Summary


User
  ↓
Load Balancer
  ↓
API Server
  ↓
Original Storage
  ↓
Transcoding Server
  ↓
Transcoded Storage
  ↓
CDN
  ↓
User

এবং Parallelভাবে:


Metadata
  ↓
API Server
  ↓
Cache + Database

Video Streaming Flow (পরিচিতি)

যখন আপনি YouTube-এ Video Play করেন,

তখন পুরো Video Download হয় না।

বরং Video ছোট ছোট অংশে Stream হয়।

Downloading

পুরো Video Device-এ Copy হয়।

Streaming

ভিডিওর ছোট ছোট অংশ ধারাবাহিকভাবে আসে।

ফলে:

দ্রুত Start হয়
কম অপেক্ষা করতে হয়
Smooth Playback পাওয়া যায়

Part 2 শেষ

Part 3-এ থাকবে:

Video Streaming Deep Dive

Streaming Protocol
MPEG-DASH
HLS
CDN Streaming
Video Transcoding
Bitrate
Codec
Container
কেন Transcoding সবচেয়ে গুরুত্বপূর্ণ Component

এগুলো System Design Interview-এ সবচেয়ে বেশি জিজ্ঞাসা করা হয়।

Part 3 — Video Streaming Deep Dive & Video Transcoding

আগের অংশে আমরা Video Upload Flow দেখেছি।

এখন আমরা YouTube-এর সবচেয়ে গুরুত্বপূর্ণ অংশগুলোর একটি নিয়ে আলোচনা করব:

Video Streaming Flow

যখন আপনি YouTube-এ একটি ভিডিও চালু করেন, সাধারণত ভিডিও সঙ্গে সঙ্গেই প্লে হওয়া শুরু করে।

আপনাকে পুরো ভিডিও Download হওয়ার জন্য অপেক্ষা করতে হয় না।

Download বনাম Streaming

Download

ডাউনলোডের ক্ষেত্রে:

পুরো ভিডিও আপনার ডিভাইসে কপি হয়
সম্পূর্ণ ফাইল নামার পর দেখা যায়

উদাহরণ:


1 GB ভিডিও
↓
পুরো 1 GB Download
↓
তারপর Play

Streaming

স্ট্রিমিংয়ের ক্ষেত্রে:

ভিডিও ছোট ছোট অংশে আসে।


ভিডিও
↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4
...

ফলে:

সঙ্গে সঙ্গে প্লে শুরু হয়
অপেক্ষা কম লাগে
Buffering কম হয়

Streaming Protocol

ভিডিও Streaming করার জন্য Standard Protocol ব্যবহার করা হয়।

এগুলো Video Data Transfer নিয়ন্ত্রণ করে।

Interview-এর জন্য কী জানা দরকার?

প্রোটোকলের নাম মুখস্থ করা জরুরি নয়।

যা গুরুত্বপূর্ণ:

ভিন্ন Streaming Protocol ভিন্ন Video Encoding ও Player Support করে।

তাই Streaming Service ডিজাইন করার সময় সঠিক Protocol নির্বাচন করতে হয়।

CDN থেকে Video Streaming

ভিডিও সরাসরি CDN থেকে Stream হয়।

Edge Server

CDN-এর অনেকগুলো Server থাকে।

ব্যবহারকারীর সবচেয়ে কাছের Server-কে Edge Server বলা হয়।

উদাহরণ:

বাংলাদেশের একজন User ভিডিও দেখছে।

তখন ভিডিও সম্ভবত:


Singapore Edge Server
বা
India Edge Server

থেকে আসবে।

সুবিধা

কম Latency
দ্রুত Load
কম Buffering

Video Transcoding

এটি YouTube Architecture-এর অন্যতম গুরুত্বপূর্ণ অংশ।

Transcoding কী?

ভিডিওকে বিভিন্ন Format, Resolution এবং Bitrate-এ Convert করার প্রক্রিয়াকে Transcoding বলে।

ধরা যাক একজন Creator Upload করল:


video.mov

এখন System তৈরি করবে:


360p.mp4
480p.mp4
720p.mp4
1080p.mp4
4K.mp4

কেন Transcoding দরকার?

১. Raw Video বিশাল Storage ব্যবহার করে

উদাহরণ:


1 ঘণ্টার HD ভিডিও
60 FPS

সহজেই কয়েকশ GB হতে পারে।

২. সব Device একই Format Support করে না

উদাহরণ:

কিছু Browser Support করে:


H.264

আবার কিছু Device Support করে:

VP9

তাই Compatibility-এর জন্য Transcoding দরকার।

৩. Network Speed ভিন্ন হয়

সব User-এর Internet একই নয়।

উদাহরণ:

Fast Internet


100 Mbps

User:


1080p

ভিডিও দেখতে পারবে।

Slow Internet


2 Mbps

User:


360p

দেখবে।

Adaptive Streaming

Network Speed পরিবর্তন হলে Video Quality-ও পরিবর্তন হয়।

উদাহরণ:

প্রথমে:


1080p

চলছিল।

নেটওয়ার্ক Slow হয়ে গেল।

System Automatically Switch করবে:


720p
↓
480p
↓
360p

ফলে ভিডিও বন্ধ হয় না।

Container এবং Codec

অনেকেই এই দুইটি গুলিয়ে ফেলে।

Container

Container হচ্ছে Video File-এর Wrapper।

এতে থাকে:

Video
Audio
Metadata

উদাহরণ:


.mp4
.mov
.avi
.mkv

ভাবুন Container হলো একটি ব্যাগ।

Codec

Codec হলো Compression/Decompression Algorithm।

কাজ:


ভিডিও ছোট করা
কিন্তু Quality যত সম্ভব ধরে রাখা

উদাহরণ

ধরা যাক:


movie.mp4

এখানে:


mp4 = Container

এবং ভিতরে থাকতে পারে:


H.264 Codec

DAG Model

ভিডিও Transcoding খুব ব্যয়বহুল (Computationally Expensive)।

সব Creator-এর Requirement এক নয়।

কেউ চায়:


Watermark

কেউ চায়:


Thumbnail Auto Generate

কেউ Upload করে:


4K Video

কেউ Upload করে:


720p Video

তাই Flexible Architecture দরকার।

Directed Acyclic Graph (DAG)

Facebook-এর Video Processing Engine DAG ব্যবহার করে।

আমরাও একই Concept ব্যবহার করব।

DAG কী?

ভিডিও Processing-কে ছোট ছোট Task-এ ভাগ করা।

উদাহরণ:


Video Upload
    ↓
Inspection
    ↓
Encoding
    ↓
Thumbnail
    ↓
Watermark
    ↓
Final Video

কিছু Task Sequential হতে পারে।

কিছু Task Parallel হতে পারে।

Video Processing Pipeline

Original Video ভেঙে ফেলা হয়:


Video
Audio
Metadata

এরপর বিভিন্ন Task চলে।

Inspection

ভিডিও Valid কিনা পরীক্ষা করা।

চেক করা হয়:

File Corrupt কিনা
Video Quality ঠিক আছে কিনা

Video Encoding

ভিডিওকে বিভিন্ন Resolution-এ Convert করা।

উদাহরণ:


360p.mp4
480p.mp4
720p.mp4
1080p.mp4
4K.mp4

Thumbnail Generation

Thumbnail হতে পারে:

User Upload করা

অথবা

Automatically Generate

Watermark

ভিডিওর উপর Logo বা Branding বসানো।

উদাহরণ:


Company Logo

Final Assembly

শেষে System একত্র করে:


Encoded Video
+
Encoded Audio
+
Metadata

এবং Final Output তৈরি করে।

উদাহরণ:


funny_video_720p.mp4

Video Transcoding Summary

Video Upload ↓

Split into:


Video
Audio
Metadata

↓

Tasks


Inspection
Encoding
Thumbnail
Watermark

↓

Assembly

↓

Final Encoded Video

↓

CDN

↓

User

Part 3 শেষ

Part 4-এ থাকবে সবচেয়ে গুরুত্বপূর্ণ Architecture Section:

Video Transcoding Architecture

Preprocessor
GOP
DAG Scheduler
Resource Manager
Task Queue
Worker Queue
Running Queue
Task Workers
Temporary Storage

এটি সাধারণত Senior System Design Interview-এর Deep Dive অংশ।

Part 4 — Video Transcoding Architecture (Deep Dive)

আগের অংশে আমরা দেখেছি Transcoding কেন দরকার এবং DAG Model কীভাবে কাজ করে।

এখন আমরা YouTube-এর Video Processing Pipeline-এর Architecture বিস্তারিতভাবে দেখব।

Video Transcoding Architecture Overview

Cloud Service ব্যবহার করে একটি Scalable Transcoding Architecture তৈরি করা হয়েছে।

এখানে ৬টি প্রধান Component রয়েছে:


Preprocessor
      ↓
DAG Scheduler
      ↓
Resource Manager
      ↓
Task Workers
      ↓
Encoded Video

এবং পাশাপাশি:


Temporary Storage

ব্যবহৃত হয়।

1. Preprocessor

Transcoding Pipeline-এর Entry Point।

ভিডিও আপলোড হওয়ার পর প্রথমে Preprocessor সেটি Handle করে।

Preprocessor-এর ৪টি প্রধান দায়িত্ব

1. Video Splitting

ভিডিওকে ছোট ছোট অংশে ভাগ করা হয়।

এগুলোকে বলা হয়:

GOP (Group Of Pictures)

GOP কী?

GOP হলো কিছু Video Frame-এর Group।

সাধারণত:


২–১০ সেকেন্ড

দৈর্ঘ্যের Chunk হয়।

উদাহরণ:


Original Video
      ↓

GOP1
GOP2
GOP3
GOP4
...
GOPN

কেন GOP ব্যবহার করা হয়?

কারণ:

Parallel Processing সম্ভব হয়
Upload Resume করা যায়
Encoding দ্রুত হয়

ধরা যাক:

১০০ MB Upload হয়েছে।

এরপর Internet Disconnect হয়ে গেছে।

পুরো Video আবার Upload করতে হবে না।

শুধু Missing GOP Upload হবে।

2. Legacy Client Support

কিছু পুরনো Device বা Browser GOP Split Support করে না।

উদাহরণ:

পুরনো Android Browser
পুরনো Smart TV

এক্ষেত্রে:

Preprocessor Server Side-এ GOP Split করে।

3. DAG Generation

এটি Preprocessor-এর অন্যতম গুরুত্বপূর্ণ কাজ।

Client Programmer Configuration File লিখবে।

Preprocessor সেই Config পড়ে DAG তৈরি করবে।

উদাহরণ:


Download
    ↓
Transcode

এটি একটি DAG।

এখানে:

২টি Node
১টি Edge

আছে।

Configuration Example

প্রথম Task:


download-input

কাজ:


ভিডিও Download করা

দ্বিতীয় Task:


transcode

কাজ:


ভিডিও Encode করা

Flow:


Download
    ↓
Transcode

Preprocessor এই Config File থেকে DAG Generate করে।

4. Cache Data

Preprocessor Temporary Cache হিসেবেও কাজ করে।

এখানে Store করা হয়:


GOP Segments
Metadata

কেন?

ধরা যাক:

Encoding মাঝপথে Fail করল।

তখন আবার পুরো Video Process করতে হবে না।

Temporary Storage থেকে Resume করা যাবে।

DAG Scheduler

এখন DAG Scheduler নিয়ে আলোচনা করি।

DAG Scheduler-এর কাজ

DAG-কে বিভিন্ন Stage-এ ভাগ করা।

ধরা যাক:

Original Video এসেছে।

Stage 1:


Video
Audio
Metadata

এ বিভক্ত করা হলো।

Stage 2:

Video অংশ থেকে:


Video Encoding
Thumbnail Generation

Audio অংশ থেকে:


Audio Encoding

Flow:


Original Video
       ↓

Stage 1
 ├── Video
 ├── Audio
 └── Metadata

       ↓

Stage 2

Video → Encode
Video → Thumbnail

Audio → Encode

DAG Scheduler-এর মূল কাজ

Task-গুলোকে Stage অনুযায়ী ভাগ করা।

এরপর সেই Task Resource Manager-এর Queue-তে পাঠানো।

Resource Manager

এটি পুরো System-এর Brain।

কাজ:


কোন Task
কোন Worker
কখন Execute করবে

নির্ধারণ করা।

Resource Manager-এর মধ্যে থাকে:


Task Queue
Worker Queue
Running Queue
Task Scheduler

Task Queue

এখানে Execute করার জন্য অপেক্ষমাণ Task থাকে।

উদাহরণ:


Thumbnail Task
Video Encode Task
Watermark Task

সাধারণত এটি:


Priority Queue

হয়।

অর্থাৎ গুরুত্বপূর্ণ কাজ আগে চলবে।

Worker Queue

এখানে Worker-এর Status থাকে।

উদাহরণ:


Worker A → Idle
Worker B → Busy
Worker C → 20% Load

এটিও Priority Queue।

Running Queue

বর্তমানে চলমান Task-এর তথ্য রাখে।

উদাহরণ:


Task #101
Running on Worker B

Task #102
Running on Worker C

Task Scheduler

এটি Resource Manager-এর সবচেয়ে গুরুত্বপূর্ণ অংশ।

কাজ:

Step 1

Task Queue থেকে Highest Priority Task নেওয়া।

Step 2

Worker Queue থেকে Best Worker খুঁজে বের করা।

Step 3

Worker-কে Task Assign করা।

Step 4

Task + Worker তথ্য Running Queue-তে রাখা।

Step 5

Task শেষ হলে Running Queue থেকে Remove করা।

Resource Manager Example

ধরা যাক:

Task Queue:


Thumbnail
Encoding
Watermark

Worker Queue:


Worker A → Busy
Worker B → Idle
Worker C → Idle

Task Scheduler:


Encoding Task
↓
Worker B

Assign করবে।

Task Workers

Task Worker-রা আসল Processing করে।

DAG-এ যে Task Define করা আছে,

সেগুলো Worker Execute করে।

Worker Types

Watermark Worker

ভিডিওতে Watermark বসায়।

উদাহরণ:


Company Logo

Encoder Worker

ভিডিও Encode করে।

উদাহরণ:


360p
720p
1080p
4K

তৈরি করে।

Thumbnail Worker

Thumbnail Generate করে।

উদাহরণ:


frame_120.jpg

Merger Worker

Audio + Video + Metadata Merge করে।

Final Output তৈরি করে।

Temporary Storage

Video Processing চলাকালীন Intermediate Data সংরক্ষণ করা হয়।

এখানে বিভিন্ন Storage ব্যবহার করা যেতে পারে।

Storage নির্বাচন নির্ভর করে:


Data Type
Data Size
Access Frequency
Data Lifetime

এর উপর।

Metadata Storage

Metadata ছোট হয়।

বারবার Access করা হয়।

তাই:


Memory Cache

ব্যবহার করা ভালো।

Video / Audio Storage

এগুলো বড় File।

তাই:


Blob Storage

ব্যবহার করা হয়।

উদাহরণ:

Amazon S3
Google Cloud Storage

Temporary Data Cleanup

Video Processing শেষ হলে:


Temporary Data

Delete করে দেওয়া হয়।

ফলে Storage Cost কমে।

Encoded Video

এটি পুরো Pipeline-এর Final Output।

উদাহরণ:


funny_360p.mp4
funny_720p.mp4
funny_1080p.mp4
funny_4k.mp4

এগুলো পরে:

CDN

এ Upload করা হয়।

সেখান থেকে User Video Stream করে।

পুরো Architecture Summary


Original Video
       ↓

Preprocessor
       ↓

DAG Generation
       ↓

DAG Scheduler
       ↓

Resource Manager
       ↓

Task Queue
       ↓

Task Workers

 ├── Encoder
 ├── Thumbnail
 ├── Watermark
 └── Merger

       ↓

Encoded Video
       ↓

CDN
       ↓

User

Part 4 শেষ

Part 5-এ থাকবে:

System Optimizations

Parallel Video Upload
GOP-based Upload
Upload Centers
Global Upload Architecture
Message Queue Based Processing
Pre-signed URL Security
DRM
AES Encryption
Watermarking

এগুলো বাস্তব YouTube-সদৃশ Production System-এর সবচেয়ে গুরুত্বপূর্ণ Optimization Techniques।

Part 5 — System Optimizations (Speed, Security & Cost Optimization)

এ পর্যন্ত আমরা Video Uploading, Streaming এবং Transcoding Architecture দেখেছি।

এখন আমরা Production-Grade YouTube System-এর জন্য গুরুত্বপূর্ণ Optimization Technique গুলো দেখব।

Speed Optimization 1 — Parallel Video Upload

পুরো ভিডিওকে একসাথে Upload করা খুব Efficient নয়।

ধরা যাক:


5 GB Video

যদি Upload-এর মাঝপথে Network Disconnect হয়ে যায়:


4.8 GB Upload Complete
↓
Connection Lost
↓
Restart Upload

তাহলে আবার শুরু থেকে Upload করতে হবে।

এটি অত্যন্ত ধীর এবং ব্যয়বহুল।

সমাধান

ভিডিওকে GOP Chunk-এ ভাগ করা।

উদাহরণ:


Original Video
    ↓

GOP1
GOP2
GOP3
GOP4
...
GOPN

এখন প্রতিটি GOP আলাদা Upload হবে।

যদি Upload Fail করে:


GOP1 ✓
GOP2 ✓
GOP3 ✓
GOP4 ✗

তাহলে শুধু GOP4 পুনরায় Upload হবে।

পুরো Video নয়।

সুবিধা

Faster Upload

Resumable Upload

Better Reliability

Parallel Processing

Speed Optimization 2 — Upload Center Users-এর কাছে রাখা

আরেকটি বড় Optimization হলো:

User-এর কাছাকাছি Upload Center স্থাপন করা।

সমস্যা

ধরা যাক:

বাংলাদেশের User Video Upload করছে।

কিন্তু Server রয়েছে:


United States

তাহলে:

Latency বাড়বে
Upload Slow হবে

সমাধান

Global Upload Centers

উদাহরণ:


North America Upload Center

Europe Upload Center

Asia Upload Center

South America Upload Center

বাংলাদেশের User Upload করবে:


Asia Upload Center

এ।

বাস্তবে কী ব্যবহার করা যায়?

CDN Upload Endpoint

অর্থাৎ:

CDN শুধু Download-এর জন্য নয়,

Upload-এর জন্যও ব্যবহার করা যায়।

সুবিধা

কম Latency

দ্রুত Upload

ভালো User Experience

Speed Optimization 3 — Parallelism Everywhere

Low Latency System তৈরির জন্য High Parallelism অত্যন্ত গুরুত্বপূর্ণ।

সমস্যা

ধরা যাক Processing Flow:


Download
   ↓
Encode
   ↓
Upload
   ↓
CDN

এখানে:

Encoding শুরু করতে হলে

Download শেষ হওয়ার জন্য অপেক্ষা করতে হবে।

Upload শুরু করতে হলে

Encoding শেষ হওয়ার জন্য অপেক্ষা করতে হবে।

একে বলে:


Tightly Coupled System

সমস্যা

Slow
Bottleneck
Scalability কম

Solution — Message Queue

System-কে Loosely Coupled করা।

উদাহরণ:


Download
     ↓

Message Queue

     ↓

Encoding

     ↓

Message Queue

     ↓

Upload

     ↓

Message Queue

     ↓

CDN

সুবিধা

Download Module Failure হলেও

Encoding Module বন্ধ হবে না।

যখন Queue-তে কাজ থাকবে,

Worker গুলো Parallelভাবে কাজ করতে পারবে।

Example

ধরা যাক:

Queue-তে 100 Encoding Job আছে।

তখন:


Worker 1
Worker 2
Worker 3
Worker 4
Worker 5

একসাথে কাজ করবে।

ফলে Throughput অনেক বেড়ে যায়।

Security Optimization 1 — Pre-Signed Upload URL

Security অত্যন্ত গুরুত্বপূর্ণ।

সমস্যা

যদি User সরাসরি Storage Access পায়,

তাহলে:

Unauthorized Upload
Data Corruption
Security Risk

হতে পারে।

Solution

Pre-Signed URL

Flow

Step 1

Client Request পাঠায়:


POST /upload

Step 2

API Server একটি


Pre-Signed URL

Generate করে।

উদাহরণ:


https://storage...
?token=abc123

Step 3

Client সেই URL ব্যবহার করে Video Upload করে।

সুবিধা

User সরাসরি Storage Access পায় না।

শুধুমাত্র নির্দিষ্ট File Upload করার Permission পায়।

Cloud Examples

Amazon S3


Pre-Signed URL

Azure Blob Storage


Shared Access Signature (SAS)

একই ধারণা।

Security Optimization 2 — Video Protection

অনেক Creator তাদের Original Video চুরি হয়ে যাওয়ার ভয় পান।

তাই Copyright Protection দরকার।

Method 1 — DRM

DRM =


Digital Rights Management

প্রধান DRM Solution:

Apple FairPlay

Google Widevine

Microsoft PlayReady

DRM কী করে?

ভিডিওকে Protected করে।

শুধুমাত্র Authorized Device Video Play করতে পারে।

Method 2 — AES Encryption

ভিডিও Encrypt করা হয়।

Playback-এর সময়:


Encrypted Video
        ↓
Authorized User
        ↓
Decrypt
        ↓
Play

Unauthorized User Video দেখতে পারবে না।

Method 3 — Visual Watermark

ভিডিওর উপর Logo বা Text বসানো।

উদাহরণ:


Company Logo

OR

Company Name

ফলে Video Leak হলেও Source শনাক্ত করা সহজ হয়।

Cost Saving Optimization

CDN অত্যন্ত ব্যয়বহুল।

আমাদের Estimation অনুযায়ী:


~ $150,000/day

খরচ হতে পারে।

তাই Cost কমাতে হবে।

Long Tail Distribution

Research দেখায়:

YouTube Video সাধারণত


Long Tail Distribution

Follow করে।

অর্থাৎ:

কিছু Video খুব জনপ্রিয়।

বেশিরভাগ Video খুব কম দেখা হয়।

উদাহরণ:


Video A
100 Million Views

Video B
12 Views

Optimization 1

সব Video CDN-এ রাখব না।

Less Popular Videos

রাখব:


Video Storage Server

এ।

ফলে CDN Cost কমে।

Optimization 2

সব Video-এর সব Resolution তৈরি করব না।

ধরা যাক:


10 View Video

এর জন্য:


360p
480p
720p
1080p
4K

সব Generate করা অপচয়।

এর পরিবর্তে:


On-Demand Encoding

করা যায়।

User চাইলে তখন Encode হবে।

Optimization 3

Regional Popularity

কিছু Video নির্দিষ্ট Region-এ জনপ্রিয়।

উদাহরণ:

বাংলাদেশের একটি স্থানীয় Video।

এটি:


USA CDN
Brazil CDN
Europe CDN

এ Replicate করার দরকার নেই।

শুধু Asia Region-এ রাখলেই যথেষ্ট।

ফলে:

Storage Cost

এবং

CDN Cost

দুটোই কমে।

Optimization 4 — Build Your Own CDN

Netflix-এর মতো বড় কোম্পানি নিজেদের CDN তৈরি করে।

এবং ISP-এর সাথে Partnership করে।

ISP উদাহরণ:

Comcast
Verizon
AT&T

ইত্যাদি।

ফলে:

Bandwidth Cost কমে
Latency কমে
User Experience উন্নত হয়

তবে এটি বিশাল Project।

সাধারণ কোম্পানির জন্য:


Cloud CDN

ব্যবহার করাই ভালো।

Optimization Summary

Speed

GOP Upload
Parallel Upload
Multiple Upload Centers
Message Queue
Parallel Processing

Security

Pre-Signed URL
DRM
AES Encryption
Watermark

Cost

Popular Content → CDN
Less Popular → Storage Server
On-Demand Encoding
Regional Distribution
Custom CDN

Part 5 শেষ

পরবর্তী Part 6 (Final Part)-এ থাকবে:

Error Handling
Recoverable vs Non-Recoverable Error
Upload Failure Recovery
Queue Failure Recovery
Database Failure Recovery
Cache Failure Recovery
Live Streaming Discussion
Database Scaling
API Scaling
Interview Wrap-Up

এবং পুরো YouTube System Design-এর চূড়ান্ত সারাংশ।

Part 6 — Error Handling, Scaling, Live Streaming & Interview Wrap-Up

এখন আমরা YouTube System Design-এর শেষ অংশে এসেছি।

বাস্তব পৃথিবীর Large Scale System-এ Error হওয়া স্বাভাবিক।

কোনো System কখনো ১০০% Error-Free নয়।

তাই একজন System Designer-এর মূল লক্ষ্য হলো:

Error হলে System কীভাবে Recover করবে?

Error Handling

বড় Scale-এর System-এ Fault Tolerance অত্যন্ত গুরুত্বপূর্ণ।

Error-এর দুইটি প্রধান ধরন

1. Recoverable Error

এ ধরনের Error থেকে System Recovery করতে পারে।

উদাহরণ:


Video Segment Encoding Failed

কারণ হতে পারে:

Temporary Network Issue
Worker Crash
Storage Timeout

Solution

Retry Mechanism

Flow:


Task Failed
     ↓
Retry #1
     ↓
Retry #2
     ↓
Retry #3
     ↓
Success

যদি বারবার Fail করে:


Max Retry Exceeded

তাহলে Client-কে Error Return করা হয়।

2. Non-Recoverable Error

এ ধরনের Error Retry করলেও ঠিক হবে না।

উদাহরণ:


Corrupted Video

বা:


Unsupported Video Format

এক্ষেত্রে:

System সাথে সাথে Processing বন্ধ করে দেয়।

Flow:


Invalid Video
      ↓
Stop Processing
      ↓
Return Error

Component-wise Error Handling

Upload Error

উদাহরণ:


Network Disconnected

Solution:


Retry Upload

কারণ GOP Upload ব্যবহৃত হচ্ছে।

শুধুমাত্র Failed Chunk Upload হবে।

Video Split Error

ধরা যাক:

পুরনো Client GOP Split করতে পারে না।

Solution:


Server-side GOP Splitting

অর্থাৎ পুরো Video Upload হবে।

Server নিজে Split করবে।

Transcoding Error

উদাহরণ:


Encoding Failed

Solution:


Retry Encoding

Preprocessor Error

ধরা যাক:

DAG Corrupted হয়েছে।

Solution:


Regenerate DAG

DAG Scheduler Error

ধরা যাক:

কোনো Stage Scheduling Failed।

Solution:


Reschedule Task

Resource Manager Queue Failure

Queue Crash করে গেল।

Solution:


Replica Queue

Primary Queue Down হলে:

Replica Queue কাজ চালিয়ে যাবে।

Task Worker Failure

Worker মারা গেছে।

উদাহরণ:


Worker #3 Crash

Solution:


Retry Task
On Another Worker

Flow:


Worker A Failed
      ↓
Worker B

API Server Failure

API Server Stateless।

এর মানে:

কোনো Local State রাখে না।

তাই:


API Server A Down

Load Balancer Request পাঠাবে:


API Server B

এ।

User কিছু বুঝতেই পারবে না।

Metadata Cache Failure

ধরা যাক:

Cache Node মারা গেছে।

Solution:

Cache Replication

উদাহরণ:


Cache A
Cache B
Cache C

Cache A Down হলেও:


Cache B

থেকে Data পাওয়া যাবে।

পরে নতুন Cache Server তৈরি করা হবে।

Metadata Database Failure

এটি সবচেয়ে গুরুত্বপূর্ণ।

ধরা যাক:

Database Replication ব্যবহার করা হয়েছে।

Architecture:


Master
  ↓
Slave 1
Slave 2
Slave 3

Case 1: Master Down

Master Crash করেছে।

Solution:

একটি Slave Promote করা হবে।

উদাহরণ:


Slave 1
      ↓
New Master

System চলতে থাকবে।

Case 2: Slave Down

Slave Crash করেছে।

Solution:

অন্য Slave Read Request Handle করবে।

এবং নতুন Replica তৈরি হবে।

System Reliability Summary

Component	Recovery Strategy
Upload	Retry
GOP Split	Server-side Split
Transcoding	Retry
DAG	Regenerate
Scheduler	Reschedule
Queue	Replica
Worker	Retry on New Worker
API Server	Redirect
Cache	Replication
Database	Failover

Additional Interview Discussion

যদি Interview-এ সময় থাকে,

তাহলে নিচের বিষয়গুলো নিয়ে আলোচনা করতে পারেন।

API Tier Scaling

API Server Stateless।

তাই Scale করা সহজ।

উদাহরণ:


10 API Server
      ↓
100 API Server

শুধু নতুন Server যোগ করলেই হবে।

এটিকে বলে:


Horizontal Scaling

Database Scaling

Database Scale করার দুটি জনপ্রিয় উপায়:

Replication


Master
  ↓
Slaves

Read Traffic ভাগ হয়ে যায়।

Sharding

Data বিভিন্ন Database-এ ভাগ করা হয়।

উদাহরণ:


User 1-1M
→ Shard A

User 1M-2M
→ Shard B

User 2M-3M
→ Shard C

ফলে Database Scale হয়।

Live Streaming

এখন পর্যন্ত আমরা:


Video On Demand (VOD)

ডিজাইন করেছি।

অর্থাৎ:

ভিডিও আগে Upload হয়েছে।

পরে User দেখছে।

Live Streaming কী?

ভিডিও Record হওয়ার সাথে সাথে Broadcast করা।

উদাহরণ:

Football Match
Live News
Live Gaming
Webinar

VOD এবং Live Streaming-এর মিল

দুটোতেই:


Upload
Encoding
Streaming

লাগে।

পার্থক্য 1 — Latency

Live Streaming-এ Latency অত্যন্ত কম হতে হবে।

উদাহরণ:


Football Goal

ঘটার ৩০ সেকেন্ড পরে দেখালে চলবে না।

সাধারণত:


1-5 seconds

Latency লক্ষ্য থাকে।

পার্থক্য 2 — Parallelism

VOD-এ:

পুরো Video আগে থেকেই আছে।

Live Streaming-এ:

ছোট ছোট Real-Time Chunk আসে।

তাই অতিরিক্ত Parallelism দরকার হয় না।

পার্থক্য 3 — Error Handling

Live Streaming-এ:

দীর্ঘ Retry করা যায় না।

উদাহরণ:


Retry For 30 Seconds

এটি User Experience নষ্ট করবে।

তাই দ্রুত Recovery দরকার।

Video Takedown

YouTube-এর মতো Platform-এ Illegal Content Remove করার ব্যবস্থা থাকতে হবে।

উদাহরণ:

Copyright Violation

Pornography

Violence

Illegal Content

Detection হতে পারে:

Upload-এর সময়

Automated Detection

অথবা

User Report-এর মাধ্যমে

Flow:


User Report
      ↓
Moderation System
      ↓
Review
      ↓
Video Removed

Complete YouTube Architecture Summary


User
   ↓

Load Balancer
   ↓

API Servers
   ↓

Metadata Cache
Metadata DB

   ↓

Original Storage
   ↓

Preprocessor
   ↓

DAG Scheduler
   ↓

Resource Manager
   ↓

Task Workers

 ├─ Encoder
 ├─ Thumbnail
 ├─ Watermark
 └─ Merger

   ↓

Encoded Storage
   ↓

CDN
   ↓

Users Worldwide

Interview Takeaways

YouTube System Design Interview-এ সাধারণত Interviewer যা দেখতে চান:

Functional Requirements

Upload Video
Watch Video

Non-Functional Requirements

Scalability
Availability
Reliability
Security
Cost Efficiency

Deep Dive Topics

CDN
Video Transcoding
DAG Architecture
Message Queue
Storage
Database Sharding
Replication
Error Recovery

Final Conclusion

YouTube-এর মতো Video Streaming Platform তৈরি করা শুধু Video Upload এবং Play Button-এর বিষয় নয়।

এর পেছনে কাজ করে:

Distributed Storage
CDN
Video Transcoding Pipeline
DAG Processing
Queue-Based Architecture
Security Mechanism
Global Scaling Strategy
Cost Optimization
Fault Tolerance

এই Architecture-এর মূল লক্ষ্য হলো:

বিশ্বের কোটি কোটি ব্যবহারকারীর কাছে দ্রুত, নির্ভরযোগ্য এবং কম খরচে ভিডিও পৌঁছে দেওয়া।

🎉 অভিনন্দন! আপনি এখন YouTube System Design অধ্যায়টির সম্পূর্ণ বাংলা অনুবাদ শেষ করেছেন।