Video Streaming (YouTube/Netflix) ডিজাইন

YouTube-এ একটা video upload করে দিলে কয়েক মিনিট পর সেটা 144p থেকে 4K পর্যন্ত নানা quality-তে, পৃথিবীর যেকোনো প্রান্তে, যেকোনো net speed-এ smooth চলে। এর পেছনে আছে বিশাল transcoding pipeline আর global CDN। চলো একজন senior engineer-এর দৃষ্টিতে পুরো system ভেঙে দেখি।

১. সমস্যা বোঝা (Requirements)

Functional Requirements:

• Video upload করা।
• Upload হওয়া video কে নানা resolution-এ process করা (240p, 480p, 720p, 1080p, 4K)।
• Video stream/playback করা, যেকোনো ডিভাইসে।
• Adaptive quality — net speed অনুযায়ী quality বদলানো।
• View count, like, comment।
• Search ও basic recommendation।

Non-functional Requirements:

• High availability — সার্ভিস কখনো বন্ধ হবে না।
• Low latency playback — video শুরু হতে যেন দেরি না হয়।
• Scalability — কোটি কোটি ঘণ্টা video, কোটি দর্শক।
• Durability — upload হওয়া video কখনো হারাবে না।
• Read-heavy — দেখা হয় লেখার চেয়ে হাজার গুণ বেশি।

২. স্কেল আন্দাজ (Estimation)

ধরি:
DAU                            = 100 কোটি = 1B
গড়ে প্রতি user/দিন video দেখে   = 5 টি
মোট view/দিন                   = 5 বিলিয়ন
read QPS গড়                   = 5B / 86400 ≈ 58,000 view/sec
পিক (×3)                       ≈ 175,000 view/sec

Upload:
প্রতি মিনিটে upload            ≈ 500 ঘণ্টা video (YouTube-এর কাছাকাছি)
প্রতি ঘণ্টা raw video (1080p)  ≈ 2 GB

Storage (transcoding-এর পর সব resolution মিলে ~2× source):
প্রতি মিনিটে                   = 500 ঘণ্টা × 2 GB × 2 ≈ 2 TB/মিনিট
প্রতি দিন                      ≈ 2 TB × 60 × 24 ≈ 2.8 PB/দিন

Bandwidth (delivery):
175,000 concurrent stream × 5 Mbps ≈ 875 Gbps পিক

মূল শিক্ষা: storage ও bandwidth দুটোই বিশাল — তাই blob storage + CDN ছাড়া উপায় নেই, আর এটা প্রবলভাবে read-heavy।

৩. API ডিজাইন

// Upload (বড় ফাইল, তাই resumable/multipart)
POST /v1/videos/upload-url        // pre-signed upload URL চাওয়া
PUT  <pre-signed-url>             // সরাসরি blob storage-এ chunk আপলোড
POST /v1/videos                   // metadata জমা (title, desc)

// Playback
GET  /v1/videos/{id}             // metadata + manifest URL
GET  /v1/videos/{id}/manifest.m3u8   // HLS manifest (quality list)
GET  <cdn>/segments/{id}/720p/seg_003.ts  // আসল video chunk

// Engagement
POST /v1/videos/{id}/view        // view count
GET  /v1/feed                    // recommendation feed

৪. ডেটা মডেল

Table/Collection	মূল field
videos (metadata)	video_id, user_id, title, description, status, duration, created_at
video_assets	video_id, resolution, codec, manifest_path, storage_url
users	user_id, name, channel_info
views / counters	video_id, view_count, like_count
comments	comment_id, video_id, user_id, text, created_at

SQL vs NoSQL choice: Video নিজে (বাইনারি ফাইল) কখনো DB-তে রাখা হয় না — সেটা যায় blob storage (S3/GCS), DB-তে থাকে শুধু path/URL। Metadata (title, owner, duration) structured ও relational, তাই SQL (sharded MySQL/Postgres) ভালো। কিন্তু view count-এর মতো প্রচণ্ড high-write counter-এর জন্য NoSQL/Redis + পরে aggregate ব্যবহার করা হয়, কারণ প্রতিবার DB row lock করলে স্কেল করবে না।

৫. হাই-লেভেল ডিজাইন

মূল components:

• Client/Player: HLS/DASH চালায়, quality বদলায়।
• Load Balancer + API servers: metadata ও request সামলায়।
• Blob Storage (S3/GCS): raw upload ও সব transcoded chunk রাখে।
• Transcoding Pipeline: message queue + worker fleet।
• Metadata DB: video info।
• CDN: global delivery।
• Cache (Redis): hot metadata ও counter।

Upload flow:

1. Client pre-signed URL নিয়ে video সরাসরি blob storage-এ upload করে (API server-কে bypass করে)।
2. Upload শেষ হলে একটা message queue (Kafka)-তে যায়: "এই video process করো"।
3. Transcoding workers raw video নেয়, chunk-এ ভাঙে, প্রতিটি resolution-এ encode করে, আবার blob storage-এ রাখে এবং HLS/DASH manifest তৈরি করে।
4. Metadata DB-তে status ready হয়।

Playback flow:

1. Client video খোলে → API থেকে metadata + manifest URL পায়।
2. Player manifest পড়ে quality-গুলোর তালিকা পায়।
3. Player তার net speed দেখে উপযুক্ত quality-র chunk গুলো CDN থেকে একে একে টানে।
4. Net বদলালে পরের chunk আলাদা quality-তে নেয় (adaptive)।

৬. গভীরে (Deep Dive)

Transcoding Pipeline ও Chunking

Transcoding হলো একটা source video-কে বিভিন্ন resolution ও codec-এ রূপান্তর করা, যাতে কম-দামি ফোন থেকে 4K টিভি সবখানে চলে। কিন্তু একটা 2 ঘণ্টার video পুরোটা একবারে process করা ধীর। তাই video কে ছোট ছোট chunk (যেমন 4-10 সেকেন্ডের segment) এ ভাঙা হয়, আর প্রতিটি chunk আলাদা worker সমান্তরালে (parallel) process করে। এতে একটা দীর্ঘ video কয়েক মিনিটেই ready হয়ে যায়। পুরো জিনিসটা একটা DAG (ধাপে ধাপে কাজ) হিসেবে চলে: split → transcode → package → manifest তৈরি।

Adaptive Bitrate Streaming (HLS/DASH)

Adaptive Bitrate মানে network অনুযায়ী quality নিজে থেকে বদলানো। কাজটা হয় manifest ফাইল দিয়ে — এতে প্রতিটি quality-র chunk-এর তালিকা থাকে। Player প্রতিটি chunk download-এর গতি মেপে সিদ্ধান্ত নেয় পরের chunk কোন quality-তে নেবে। net ভালো → 1080p; বাফার কমতে শুরু করল → চুপচাপ 480p-তে নেমে যায়, ভিডিও থামে না। HLS (Apple) আর DASH এই দুটোই জনপ্রিয় protocol, দুটোই chunk + manifest ভিত্তিক।

CDN ও Blob Storage

Blob Storage (S3/GCS) হলো বিশাল, সস্তা, durable object store — এখানে raw ও transcoded সব ফাইল থাকে; এটা "origin"। কিন্তু সব দর্শককে origin থেকে serve করলে দূরত্বের কারণে latency বেশি আর origin-এর উপর চাপ অসহনীয়। তাই CDN (Content Delivery Network) — পৃথিবীজুড়ে edge server — জনপ্রিয় video chunk cache করে রাখে এবং দর্শকের কাছের edge থেকেই serve করে।

৭. বটলনেক ও স্কেলিং

• Delivery bandwidth: সবচেয়ে বড় খরচ ও bottleneck — CDN আর জনপ্রিয় video বেশি edge-এ cache করে সামলানো হয়।
• Transcoding compute: ভারী CPU/GPU কাজ — auto-scaling worker fleet আর priority queue (জনপ্রিয় creator আগে)।
• Metadata read: খুব read-heavy — Redis caching + read replica।
• Storage growth: কম-দেখা video নিম্ন resolution-এ রাখা বা cold storage-এ সরানো।
• Sharding: metadata DB video_id দিয়ে shard করা।
• Recommendation: আলাদা একটা ML pipeline — watch history, similar video থেকে feed তৈরি করে; মূল streaming path থেকে decoupled রাখা হয় যাতে একে অপরকে slow না করে।

৮. সারসংক্ষেপ

Video streaming-এর মূল মন্ত্র — একবার process, বহুবার serve। Upload যায় blob storage-এ, একটা parallel transcoding pipeline নানা resolution-এ chunk বানায়, adaptive bitrate (HLS/DASH) player-কে smart করে তোলে, আর CDN কোটি দর্শকের কাছে দ্রুত পৌঁছে দেয়। Metadata আলাদা DB-তে থাকে, view count আলাদা high-write path-এ, recommendation আলাদা pipeline-এ।