YouTube-এর মতো video streaming সেবা ডিজাইন

ভিডিও ভারী। Upload, অনেক মানে transcoding এবং প্রতিটি দর্শকের network-এর সাথে মানিয়ে নেওয়া streaming ডিজাইন করি।

NewsReport•২৭ অক্টোবর, ২০২৬•২ মিনিটে পড়া

লক্ষ্য: user ভিডিও upload করে; অন্যরা যেকোনো device ও network-এ মসৃণভাবে দেখে।

Requirement

বড় ভিডিও নির্ভরযোগ্যভাবে upload।
ধীর ও দ্রুত দুই connection-এই playback দ্রুত শুরু হয় এবং থামে না।
সার্চ ও metadata (শিরোনাম, view, comment)।
বিশাল read:write অনুপাত: এক upload-এ অনেক view।

অনুমান

ধরুন দিনে ৫ লাখ upload, গড় raw ২০০ MB। transcoding-এর আগে দিনে ১০০ TB raw upload, আর প্রতিটি ভিডিওর অনেক সংস্করণ তা গুণ করে। দেখার bandwidth সবকিছুর ওপরে, তাই ডিজাইনটি আসলে storage ও CDN-এর সমস্যা।

Upload

Client upload URL চায়; server object storage-এর presigned URL দেয়।
Client chunk-এ (multipart/resumable) upload করে, তাই ব্যর্থতায় গোড়া থেকে শুরু করতে হয় না।
শেষ হলে একটি event queue-তে গিয়ে প্রক্রিয়া শুরু করে।

Transcoding

Raw upload সব device-এ পাঠানো যায় না। Worker-দের pipeline:

ভিডিওকে ছোট segment-এ (কয়েক সেকেন্ড) ভাঙে।
প্রতিটি segment অনেক resolution ও bitrate-এ (যেমন ২৪০p থেকে ১০৮০p বা আরও) এবং codec-এ transcode করে।
Thumbnail বানায় ও নীতিলঙ্ঘন যাচাই করে।
ফল object storage-এ লিখে metadata আপডেট করে।

Segment-গুলো অনেক মেশিনে সমান্তরালে প্রক্রিয়া হয়, যেভাবে এটি scale করে। এটি CPU/GPU-ভারী, তাই queue ও autoscaling worker ব্যবহার হয়।

Streaming: adaptive bitrate

HLS ও MPEG-DASH-এর মতো protocol একটি manifest প্রকাশ করে, যাতে উপলব্ধ মান ও segment URL থাকে। Player segment ধরে ধরে নামায় এবং মাপা bandwidth অনুযায়ী মান বদলায়, তাই buffering-এর বদলে মানিয়ে চলে।

Delivery

Segment হলো static ফাইল, CDN-এর জন্য আদর্শ। জনপ্রিয় ভিডিও দর্শকের কাছের edge-এ cache থাকে; বিরল ভিডিও origin storage থেকে আসে। খরচ ও প্রকৌশলের বেশিরভাগ এখানেই।

Metadata ও counter

শিরোনাম, মালিক ও comment থাকে database-এ; সার্চ থাকে search index-এ। View count write-ভারী, তাই প্রতিটি view-এ row আপডেট না করে buffer (queue বা Redis) করে aggregate করুন।