Case study: video streaming — upload, transcoding আর adaptive streaming

১ · সমস্যা আর পরিধি — “পর্দা” নামের একটি কাল্পনিক ভিডিও প্ল্যাটফর্ম

এই পর্বে আমরা একটি ভিডিও প্ল্যাটফর্ম নকশা করব; নাম ধরা যাক “পর্দা” — পুরোপুরি কাল্পনিক। নির্মাতারা (creator) ফোন বা কম্পিউটার থেকে ভিডিও আপলোড করেন; দর্শকেরা মোবাইল অ্যাপ আর ব্রাউজারে দেখেন, খোঁজেন, আর দেখেন কতবার দেখা হয়েছে। এ ধরনের সেবা video-on-demand (VOD) — ভিডিও আগে থেকে জমা, দর্শক যখন খুশি চালান। Live শুধু বিস্তার হিসেবে, অংশ ৯-এ।

আমরা পর্ব ৬-এর আট ধাপের কাঠামো ধরে এগোব: পরিধি → হিসাব → API → data model → বড় ছবি → গভীরে নামা → ভাঙন → সারাংশ। Case study-র কাজ নতুন ধারণা শেখানো নয়, আগের পর্বগুলো জোড়া দেওয়া — তাই প্রতিটি পুরোনো ধারণায় এক বাক্যের প্রয়োগ আর একটি link.

Functional requirement — কী করতে হবে

• আপলোড: কয়েক MB থেকে কয়েক GB; network কাটলে যেখানে থেমেছিল সেখান থেকে আবার।
• প্রক্রিয়া আর প্রকাশ: ২৪০p থেকে ১০৮০p — কয়েকটি মান, thumbnail, তারপর “প্রকাশিত”; নির্মাতা অবস্থা দেখবেন।
• দেখা: মোবাইল আর ওয়েবে দ্রুত শুরু, seek, আর গতি অনুযায়ী নিজে থেকে মান বদল।
• খোঁজা: শিরোনাম, বিবরণ, tag দিয়ে search; নির্মাতার পাতা।
• View count: একটু দেরিতে আর আনুমানিক হলেও চলবে।

Non-functional requirement — কতটা ভালোভাবে

• দেখার availability সবচেয়ে বেশি: আপলোড থামলে বিরক্তি, দেখা থামলে দর্শক হারানো — তাই পড়ার পথে কম নির্ভরতা (পর্ব ৫)।
• শুরুর দেরি আর থামা কম: ধরা যাক প্রায় ২ সেকেন্ডে প্রথম ছবি, আর দেখার খুব ছোট অংশে rebuffering — লক্ষ্য, p95 ধরে মাপা (পর্ব ৪)।
• দুর্বল network সয়ে চলা: বাংলাদেশসহ অনেক দেশে দর্শকের বড় অংশ মোবাইল ডেটায়, বদলাতে থাকা গতিতে দেখেন বলে ধরে নেওয়া যুক্তিসংগত — নিজের মাপে যাচাই করবেন।
• Durability আর প্রকাশের সময়: আসল ফাইল কখনো হারানো চলবে না (তৈরি করা মান আবার বানানো যায়); ১০ মিনিটের ভিডিও কয়েক মিনিটে দেখার যোগ্য।
• খরচ: প্রতি ঘণ্টা দেখার খরচ — মূলত বিতরণের byte — নিয়ন্ত্রণে।

পরিধির বাইরে: recommendation, comment-like, বিজ্ঞাপন, পেমেন্ট, কপিরাইট মেলানো আর moderation-এর বিস্তারিত — প্রতিটি আলাদা বড় সিস্টেম; শুধু প্রকাশের আগে একটি “যাচাই” ধাপের জায়গা রাখব।

ইন্টারভিউয়ার যে প্রশ্নগুলো আশা করেন

২ · হিসাব — storage, peak egress আর CDN বনাম origin

হিসাবের কৌশল পর্ব ৩-এ; সব ইনপুট অনুমান। মূল সংখ্যা bitrate — প্রতি সেকেন্ড ভিডিওতে কত bit; কয়েকটি মান মিলে bitrate ladder. আমাদের অনুমান: ২৪০p ০.৪, ৩৬০p ০.৮, ৪৮০p ১.৪, ৭২০p ২.৮, ১০৮০p ৫ Mbit/s — আসল মান codec আর বিষয়বস্তুভেদে অনেক আলাদা।

সূত্র তিনটি। (১) জমার আকার = bitrate × সময় ÷ ৮. (২) একসাথে দর্শক = দৈনিক দর্শক × মিনিট ÷ ১,৪৪০, তারপর peak-এর গুণক (peak factor). (৩) Peak egress = একসাথে দর্শক × গড় দেওয়া bitrate; origin পায় শুধু CDN-এর miss অংশ। নিচের calculator প্রতিটি সংখ্যা হিসাব করে।

// Back-of-the-envelope for a fictional video-on-demand platform. ALL inputs are ASSUMED.
const UPLOADS_PER_DAY = 20000;    // new videos per day
const AVG_MIN = 6;                // average video length, minutes
const RAW_MBPS = 8;               // creator's original phone video, Mbit/s
const LADDER = { "240p": 0.4, "360p": 0.8, "480p": 1.4, "720p": 2.8, "1080p": 5.0 }; // Mbit/s
const OVERHEAD = 1.5;             // durability overhead in the object store (e.g. erasure coding)
const DAU = 1e7, WATCH_MIN = 30;  // daily viewers; minutes watched per viewer per day
const PEAK = 3;                   // peak concurrency / average concurrency
const PLAY_MBPS = 1.5;            // average delivered bitrate (mobile-heavy mix)
const HIT = 0.95, SEG_S = 4;      // CDN byte hit ratio; segment length, seconds
const STARTS = 5;                 // video starts (play API calls) per viewer per day
const TB = (mbps, h) => mbps * 1e6 / 8 * 3600 * h / 1e12;   // decimal TB

const hDay = UPLOADS_PER_DAY * AVG_MIN / 60, hYear = hDay * 365;
console.log(`uploads: ${(UPLOADS_PER_DAY / 86400).toFixed(2)}/s avg, ${hDay} h/day, ${hYear} h/year`);
console.log(`upload ingress: ${(hDay * 3600 * RAW_MBPS / 86400 / 1000).toFixed(2)} Gbit/s avg`);
let ladderTB = 0;
for (const [rung, mbps] of Object.entries(LADDER)) {
  ladderTB += TB(mbps, hYear);
  console.log(`  ${rung.padEnd(6)} ${String(mbps).padStart(4)} Mbit/s  ${TB(mbps, hYear).toFixed(0).padStart(5)} TB/year`);
}
const rawTB = TB(RAW_MBPS, hYear), stored = (rawTB + ladderTB) * OVERHEAD;
console.log(`ladder ${ladderTB.toFixed(0)} TB + raw ${rawTB.toFixed(0)} TB, x${OVERHEAD} = ${(stored / 1000).toFixed(2)} PB/year`);

const avgConc = DAU * WATCH_MIN / 1440, peakConc = avgConc * PEAK;
const peakGbps = peakConc * PLAY_MBPS / 1000;
console.log(`viewers: ${avgConc.toFixed(0)} avg, ${peakConc.toFixed(0)} peak concurrent`);
console.log(`peak egress ${peakGbps.toFixed(1)} Gbit/s: CDN ${(peakGbps * HIT).toFixed(1)}, origin ${(peakGbps * (1 - HIT)).toFixed(1)}`);
const startsS = DAU * STARTS / 86400;
console.log(`play API ${startsS.toFixed(0)}/s avg, ${(startsS * PEAK).toFixed(0)}/s peak; segment GETs ${(peakConc / SEG_S).toFixed(0)}/s peak`);
const egressPBday = DAU * WATCH_MIN * 60 * PLAY_MBPS * 1e6 / 8 / 1e15;
console.log(`delivered ${egressPBday.toFixed(3)} PB/day; one year of new storage leaves every ${(stored / 1000 / egressPBday).toFixed(1)} days`);
console.log(`bytes out : bytes in = ${(egressPBday * 1e15 / (hDay * 3600 * RAW_MBPS * 1e6 / 8)).toFixed(0)} : 1`);

uploads: 0.23/s avg, 2000 h/day, 730000 h/year
upload ingress: 0.67 Gbit/s avg
  240p    0.4 Mbit/s    131 TB/year
  360p    0.8 Mbit/s    263 TB/year
  480p    1.4 Mbit/s    460 TB/year
  720p    2.8 Mbit/s    920 TB/year
  1080p     5 Mbit/s   1643 TB/year
ladder 3416 TB + raw 2628 TB, x1.5 = 9.07 PB/year
viewers: 208333 avg, 625000 peak concurrent
peak egress 937.5 Gbit/s: CDN 890.6, origin 46.9
play API 579/s avg, 1736/s peak; segment GETs 156250/s peak
delivered 3.375 PB/day; one year of new storage leaves every 2.7 days
bytes out : bytes in = 469 : 1

৩ · API আর data model — কে কী বলে, কোথায় কী থাকে

API — চারটি মূল কাজ

REST-এর নিয়ম, pagination আর idempotency key পর্ব ৮-এ। মূল কথা: ভিডিওর বাইট কখনো API server দিয়ে যায় না।

POST /v1/uploads                      Idempotency-Key: 7c1e-...-a9
{ "title": "নদীর পাড়ে বিকেল", "size": 503316480, "contentType": "video/mp4",
  "sha256": "9f2b...e41" }
→ 201 { "videoId": "v42", "uploadId": "u-88f", "partSize": 16777216, "parts": 30,
        "urls": [ { "part": 1, "url": "https://raw.store.example/...&X-Sig=..." }, ... ],
        "expiresIn": 900 }

PUT  <সই করা URL, part 1>   (সরাসরি object store-এ; উত্তরে ETag)
GET  /v1/uploads/u-88f              → { "done": [1, 2, ..., 17] }   (resume করার আগে)
POST /v1/uploads/u-88f/complete     Idempotency-Key: 7c1e-...-b0
{ "parts": [ { "part": 1, "etag": "e1" }, ... ] }
→ 202 { "videoId": "v42", "status": "processing" }

GET /v1/videos/v42/playback
→ 200 { "status": "ready", "durationS": 480,
        "manifest": "https://cdn.example/v42/r3/master.m3u8",
        "dash": "https://cdn.example/v42/r3/manifest.mpd",
        "token": "exp=1767225600~path=/v42/~sig=..." }

POST /v1/view-events                (batch, প্রতি ~৩০ সেকেন্ডে একবার)
{ "session": "s-5d1", "videoId": "v42",
  "events": [ { "t": 31, "pos": 30, "rung": "720p", "stallMs": 0 } ] }
→ 204

complete-এর উত্তর 202 Accepted — কাজ নেওয়া হয়েছে, শেষ হয়নি (দীর্ঘ কাজের API-র ধাঁচ, পর্ব ৮)। দুটি POST-ই idempotency key বহন করে, তাই দুর্বল network-এ দুবার পাঠালেও দুটি ভিডিও হয় না। view-events একটি batch — প্রতি সেকেন্ডে অনুরোধ পাঠালে ব্যাটারি আর সার্ভার দুটোরই ক্ষতি।

Data model — চার রকম ডেটা, চার রকম store

CREATE TABLE videos (
  video_id     BIGINT PRIMARY KEY,          -- Snowflake-style id, hash-sharded
  owner_id     BIGINT NOT NULL,
  title        TEXT NOT NULL,
  status       TEXT NOT NULL,               -- uploading, processing, ready, failed, removed
  duration_s   INT,
  revision     INT NOT NULL DEFAULT 0,      -- bumped on every re-encode
  visibility   TEXT NOT NULL,               -- public, unlisted, members
  created_at   TIMESTAMP NOT NULL
);
CREATE TABLE renditions (                   -- one row per quality rung
  video_id BIGINT, revision INT, rung TEXT, kbps INT, segments INT, prefix TEXT,
  PRIMARY KEY (video_id, revision, rung)
);
CREATE INDEX videos_by_owner ON videos (owner_id, created_at DESC);  -- creator page

Partition key: প্রায় সব প্রশ্ন একটি ভিডিও ধরে, তাই video_id-এর hash দিয়ে ভাগ (hash partitioning) — জনপ্রিয় নির্মাতার সব ভিডিও এক shard-এ জমে না। দাম: “এই নির্মাতার সব ভিডিও” সব shard-এ ছড়ায়, তাই owner_id-এর একটি global index, একটু দেরিতে হালনাগাদ হলেও চলে (পর্ব ২৩)। নতুন করে encode করলে নতুন revision, নতুন path — চলমান ভিডিও ভাঙে না।

Object key-এর নকশা: raw/v42/source.mp4 (আসল), media/v42/r3/720p/seg_00042.m4s (segment), media/v42/r3/master.m3u8 (manifest) ধাঁচের নাম। Key-এর বিষয়বস্তু কখনো বদলায় না, তাই CDN দীর্ঘদিন রাখে — পর্ব ১৭-এর fingerprinting-এর চিন্তা; index-এর বিস্তার পর্ব ২১-এ।

৪ · বড় ছবি — লেখার পথ আর পড়ার পথ

লেখার পথ (সবুজ): API লগইন আর quota দেখে, video_id আর status = uploading লেখে, সই করা URL দেয় (১)। বাইট যায় সরাসরি raw bucket-এ (২)। শেষ হলে একটি event (৩) workflow engine-এর DAG চালু করে; DAG segment লেখে segment bucket-এ (৪), তারপর metadata-তে ready (৫), আর search index হালনাগাদ হয়।

পড়ার পথ (নীল): দর্শকের অ্যাপ API থেকে নেয় শুধু playback তথ্য আর একটি স্বল্পমেয়াদি token; তারপর manifest আর segment আসে CDN edge থেকে; edge-এ না থাকলে shield, তারপর segment bucket. পড়ার পথে নিজের কোড প্রায় নেই — তাই transcoding বা search বন্ধ থাকলেও প্রকাশিত ভিডিও চলে।

এবার একটি ভিডিওর পুরো লেখার পথ ধাপে ধাপে দেখি — ৮ মিনিটের, ৪৮০ MiB-এর একটি ফোন-ভিডিও, part ১৬ MiB, তাই ৩০টি part:

৫ · গভীরে ক — আপলোড: resumable, যাচাই-করা, আর শেষে একটি event

Multipart upload আর presigned URL-এর পুরো কৌশল — part-এর আকার, সমান্তরাল stream, সই করা URL-এর নিরাপত্তা — পর্ব ২৬-এর অংশ ৩-এ। এখানে ভিডিওর তিনটি বিশেষ প্রশ্ন: দুর্বল network-এ শেষ পর্যন্ত পৌঁছানো, ফাইলটি ঠিক কি না, আর “শেষ হয়েছে” খবরটি যেন না হারায়।

দুর্বল network-এ শেষ পর্যন্ত — resumable upload

• ছোট part: মোবাইলে ৮–১৬ MiB — ব্যর্থ হলে কম আবার পাঠাতে হয়। কিন্তু store-এর part-সংখ্যার সীমা (লেখার সময়ে S3-ধাঁচের store-এ ১০,০০০) মানে বড় ফাইলে part বড় করতেই হয়: part ≥ ফাইল ÷ সীমা (পর্ব ২৬)।
• অবস্থা দুই জায়গায়: অ্যাপ ফোনে uploadId আর শেষ হওয়া part লিখে রাখে; কিন্তু সত্য বলে server-এর GET /v1/uploads/{id}, store-এর part-তালিকা থেকে। অ্যাপ বন্ধ হয়ে খুললেও resumable upload চলে, যতক্ষণ session-এর মেয়াদ আছে।
• URL-এর মেয়াদ ছোট, আপলোড লম্বা: দুর্বল সংযোগে ১ GB-তে এক ঘণ্টা লাগতে পারে; তাই অ্যাপ কয়েকটি করে URL চায়, ফুরোলে নতুন — ফাঁস হলেও ক্ষতি সীমিত।

খোলা মান-রূপ tus protocol-এও একই কথা: অগ্রগতির সত্য server-পাশে, প্রতিটি টুকরো আলাদাভাবে আবার পাঠানো যায়।

ফাইলটি কি ঠিক? — দুই স্তরে checksum

1. প্রতিটি part: অ্যাপ checksum header-এ পাঠায়, store নিজে হিসাব করে না মিললে part নেয় না। কোন algorithm (MD5, CRC32C, SHA-256) চলে তা store-ভেদে আলাদা। Multipart-এর ETag প্রায়ই পুরো ফাইলের MD5 নয় — তাই ETag দিয়ে পুরো ফাইল যাচাই ভুল।
2. পুরো ফাইল: অ্যাপ শুরুতেই SHA-256 জানায়; worker পড়ার সময় একই hash হিসাব করে মেলায়, না মিললে failed. একই ফাইল দুবার এলে এই hash-এই ধরা যায় — তবে বহুজনের মধ্যে মেলালে “ফাইলটি আগেই কারও আছে” তথ্য ফাঁস হতে পারে।

তারপর বিষয়বস্তুর যাচাই: প্রথম কয়েক byte দেখে আসল ধরন, আকার আর দৈর্ঘ্যের সীমা, probe, malware scan — client-এর দেওয়া নাম বা contentType বিশ্বাস নয়।

“শেষ হয়েছে” খবরটি যেন না হারায়

সত্যের উৎস একটি: API-র Complete একই transaction-এ status = processing আর outbox-এ event লেখে, relay সেটি queue-তে দেয় (পর্ব ২৫) — store-এর নিজের event notification-এর ওপর আলাদাভাবে নির্ভর করলে “database বলছে processing, কেউ কাজ শুরু করেনি” অবস্থা হতে পারে। Event আসে অন্তত একবার (পর্ব ৩৪), তাই workflow-এর পরিচয় (video_id, revision): একই জোড়া আগেই থাকলে নতুনটি শুরু হয় না — idempotent consumer. আর একটি মিলিয়ে-দেখার কাজ ৩০ মিনিটের বেশি আটকে থাকা session খোঁজে; কয়েক দিন পরে অসমাপ্ত upload মুছে দেয় lifecycle নিয়ম (পর্ব ২৬)।

৬ · গভীরে খ — Transcoding pipeline: কাজের একটি DAG, সমান্তরালে

ফোনের আসল ফাইল সরাসরি দর্শককে দেওয়া যায় না — bitrate বেশি, ফরম্যাট যেকোনো। Transcoding মানে ফাইলটি খুলে (decode), মাপে ছোট করে (scale), একটি codec-এ নির্দিষ্ট bitrate-এ আবার সংকুচিত করা (encode) — ladder-এর প্রতিটি ধাপে একবার। তারপর packaging: ছোট segment আর manifest — HLS-এর .m3u8, DASH-এর MPD, আর দুইয়ের জন্য একই fMP4 segment রাখতে CMAF (বিস্তার CN কোর্সের অংশ ৪-এ)। কাজগুলোর মধ্যে নির্ভরতা আছে, তাই এটি একটি DAG — পর্ব ৩৭-এর অংশ ৮-এর data pipeline-এর মতো, চালানোর ক্রম topological.

সমান্তরালতার অঙ্ক

এক worker-এ পুরো ভিডিও encode করলে সময় দৈর্ঘ্যের সমানুপাতিক — এক ঘণ্টার ভিডিওতে কয়েক ঘণ্টা। কৌশল: N টি টুকরো, প্রতিটি টুকরো প্রতিটি মানে একটি স্বাধীন কাজ। মোটামুটি:

তিনটি সত্য। (১) W বাড়ালে প্রথম পদ কমে, কিন্তু সবচেয়ে লম্বা কাজের নিচে নামা যায় না — ছোট টুকরো লাগে। (২) টুকরো যত ছোট, প্রতি কাজের বাড়তি খরচ (input আনা, encoder চালু, output লেখা) তত বেশিবার — বিল বাড়ে। (৩) Split আর package ভাগ হয় না — Amdahl-এর সূত্র (পর্ব ১৩)। টুকরোর সীমা বসে keyframe-এ (I-frame), নইলে টুকরোটি একা decode হয় না। নিচে ৬০ মিনিটের ভিডিও, পাঁচ মান, কাজের সময় এলোমেলো (seeded), প্রতি চেষ্টায় ৩% ব্যর্থতা — ব্যর্থ হলে কিছু কাজ নষ্ট, তারপর পরের খালি worker-এ আবার:

// Transcode a 60-min video: split into N pieces, encode every piece at 5 rungs on W workers.
// Seeded PRNG, so every run prints the same table. All costs are ASSUMED.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const VIDEO_S = 3600, COST = [0.15, 0.25, 0.4, 0.8, 1.4]; // encode seconds per video second, 240p..1080p
const TASK_OVERHEAD = 3, FAIL_P = 0.03, SPLIT_S = 30, PACKAGE_S = 40;  // seconds; failure per attempt

function run(N, W) {
  const rnd = mulberry32(59), free = new Array(W).fill(SPLIT_S);   // workers start after the split
  let work = 0, fails = 0, end = 0;
  for (let p = 0; p < N; p++) for (let r = 0; r < COST.length; r++) {
    const need = TASK_OVERHEAD + (VIDEO_S / N) * COST[r] * (0.7 + 0.9 * rnd()); // noisy encode time
    let ready = SPLIT_S;
    for (;;) {                                   // attempt until success; retry on the next free worker
      let w = 0; for (let i = 1; i < W; i++) if (free[i] < free[w]) w = i;
      const start = Math.max(free[w], ready);
      if (rnd() < FAIL_P) {                      // crash part-way: time wasted, task goes back
        const lost = need * rnd(); fails++; work += lost; free[w] = start + lost; ready = free[w]; continue;
      }
      free[w] = start + need; work += need; end = Math.max(end, free[w]); break;
    }
  }
  const wall = end + PACKAGE_S, serial = SPLIT_S + work + PACKAGE_S;
  console.log(String(N).padStart(5) + String(VIDEO_S / N).padStart(7) + String(N * COST.length).padStart(7) +
    String(W).padStart(5) + String(fails).padStart(7) + (serial / 60).toFixed(1).padStart(10) +
    (wall / 60).toFixed(1).padStart(9) + (serial / wall).toFixed(1).padStart(8) + "x");
}
console.log("    N  seg_s  tasks    W  fails  serial_min  wall_min  speedup");
for (const [N, W] of [[1, 5], [12, 20], [60, 20], [60, 100], [120, 100], [120, 300], [720, 300]]) run(N, W);

    N  seg_s  tasks    W  fails  serial_min  wall_min  speedup
    1   3600      5    5      1     247.2    158.4     1.6x
   12    300     60   20      1     211.4     17.2    12.3x
   60     60    300   20     12     228.4     13.6    16.8x
   60     60    300  100     12     228.4      5.0    46.1x
  120     30    600  100     20     245.4      5.3    46.5x
  120     30    600  300     20     245.4      3.7    66.0x
  720      5   3600  300    125     395.4      2.7   144.4x

ব্যর্থতা, retry আর idempotent কাজ

হাজারো worker-এ রোজ কিছু ভাঙবে; নিয়মগুলো পর্ব ৩৭-এর:

• Output-এর নাম নির্ধারিত: “v42, revision 1, ৭২০p, টুকরো ৭”-এর output সবসময় enc/v42/r1/720p/p07.mp4 — দুবার চললেও একই key-তে একই জিনিস, idempotent; PUT একবারে দৃশ্যমান, আধা-লেখা ফাইল কেউ দেখে না।
• Lease আর heartbeat: worker কাজ নেয় একটি lease-সহ, চলার সময় নিয়মিত heartbeat দেয়; থেমে গেলে lease ফুরোয়, কাজ আবার queue-তে।
• সীমিত চেষ্টা: backoff দিয়ে আবার; max attempts পেরোলে DLQ আর failed; বিকৃত ফাইল probe-এই ধরা ভালো (পর্ব ৩১)।
• ধীর worker: একটি straggler পুরো ভিডিও আটকায়; তার দ্বিতীয় কপি আরেক worker-এ — speculative execution (পর্ব ৩৬), idempotent বলেই নিরাপদ।

খরচ কমানোর কৌশল

কাজ ছোট আর idempotent বলে সস্তা spot বা preemptible instance চলে — ওপরের w7 ঠিক এটিই। কম দেখা ভিডিওতে শুরুতে কম মান, জনপ্রিয় হলে বাকিগুলো। আর ভিডিও-ভেদে ladder — per-title encoding: কার্টুন কম bit-এ ভালো দেখায়, খেলার দৃশ্যে বেশি লাগে; encode একটু দামি, কিন্তু প্রতিটি দেখায় byte কমে। প্রকাশিত গবেষণাতেও এই ধাঁচ: Facebook-এর প্রকৌশলীদের SOSP ২০১৭-এর “SVE” গবেষণাপত্রে আপলোড চলতে চলতেই টুকরো করে সমান্তরালে প্রক্রিয়ার বর্ণনা আছে।

৭ · গভীরে গ — Adaptive bitrate: manifest, segment আর player-এর সিদ্ধান্ত

Adaptive bitrate (ABR)-এর মূল চিন্তা, HLS-DASH-এর তুলনা আর buffer-এর গাণিতিক মডেল CN কোর্সের অংশ ৩–৪-এ। এখানে system design-এর প্রশ্ন: segment কত লম্বা, manifest কীভাবে সাজানো, আর player-এর নিয়ম সার্ভারের ভার আর দর্শকের অভিজ্ঞতা কীভাবে বদলায়।

Manifest আর segment-এর নকশা

• দুই স্তরের manifest: master (master.m3u8) — কোন মান, bitrate, resolution, codec; আর প্রতিটি মানের নিজের segment-তালিকা। VOD-এ প্রকাশের পরে এগুলো বদলায় না, তাই path-এ revision রেখে দীর্ঘ TTL (পর্ব ১৭)।
• সব মানে একই সীমানা: প্রতিটি মানের segment একই মুহূর্তে শুরু, শুরুতে keyframe — তাই segment ৪১ ৭২০p-তে আর ৪২ ৩৬০p-তে এলেও ছবি নিরবচ্ছিন্ন।
• দৈর্ঘ্য — ধরা যাক ২ থেকে ৬ সেকেন্ড: ছোট segment-এ দ্রুত শুরু আর দ্রুত মান বদল, কিন্তু বেশি অনুরোধ (৪ সেকেন্ডে peak-এ সেকেন্ডে ১,৫৬,২৫০টি GET, ২ সেকেন্ডে দ্বিগুণ) আর ঘন keyframe-এ সংকোচন কিছুটা খারাপ; লম্বায় উল্টো। আমরা ৪ সেকেন্ড ধরেছি।

দুই রকম নিয়ম, আর শুরু বনাম থামার trade-off

Throughput-ভিত্তিক: সাম্প্রতিক মাপা গতির একটি নিরাপদ অংশের মধ্যে সর্বোচ্চ মান — সরল, কিন্তু গতি হঠাৎ নামলে মাপ পিছিয়ে থাকে। Buffer-ভিত্তিক: buffer-এ কত সেকেন্ড জমা, সেটিই সংকেত। বাস্তবের player সাধারণত দুটি মিলিয়ে চলে; নিচের নিয়ম দুটি ইচ্ছা করে সরল। আর একটি টানাপোড়েন সবসময়: উঁচু মানে শুরু করলে ছবি সুন্দর, কিন্তু শুরুর দেরি আর প্রথমেই থামার ঝুঁকি বাড়ে।

নিচে একটি seeded মোবাইল-ধাঁচের গতিপথ — প্রায় ২.৫ Mbit/s-এর আশপাশে ঘোরে, মাঝে মাঝে তিন segment ধরে ৮০% পতন (লিফট, ভিড়, দুর্বল টাওয়ার)। ১৫০টি ৪ সেকেন্ডের segment (১০ মিনিট); সব নিয়মে প্রথম দুটি segment সবচেয়ে নিচু মানে, ৮ সেকেন্ড জমলে চালানো শুরু:

// ABR on a seeded, fluctuating mobile bandwidth trace: throughput rule vs buffer rule.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const LADDER = [400, 800, 1400, 2800, 5000], SEG = 4, SEGS = 150, START = 8, MAXBUF = 30; // kbps, s
const rnd = mulberry32(7), MU = Math.log(2500), trace = []; let lb = MU, drop = 0;
for (let i = 0; i < SEGS; i++) {                               // kbps during each segment fetch
  lb += 0.25 * (MU - lb) + 0.9 * (rnd() - 0.5);                // wanders around ~2.5 Mbit/s
  if (!drop && rnd() < 0.04) drop = 3;                         // lift, crowd, weak cell: 3 segments
  trace.push(Math.round(Math.exp(lb) * (drop ? (drop--, 0.2) : 1)));
}
const throughputRule = (hist) => {                             // 0.8 x harmonic mean of last 3
  if (!hist.length) return 0; const h = hist.slice(-3);
  const est = h.length / h.reduce((s, x) => s + 1 / x, 0);
  let q = 0; LADDER.forEach((b, i) => { if (b <= 0.8 * est) q = i; }); return q;
};
const bufferRule = (hist, buf) =>                              // 8 s reservoir, 8..24 s cushion
  Math.max(0, Math.min(4, Math.floor((buf - 8) / 16 * 5)));
function play(name, rule) {
  let t = 0, buf = 0, started = false, startup = 0, stalls = 0, stallT = 0, sw = 0, prev = -1, kb = 0;
  const hist = [];
  for (let i = 0; i < SEGS; i++) {
    const q = started ? rule(hist, buf) : 0, dl = LADDER[q] * SEG / trace[i];
    if (started) { if (dl > buf) { stalls++; stallT += dl - buf; buf = 0; } else buf -= dl; }
    t += dl; buf += SEG; hist.push(trace[i]); kb += LADDER[q] * SEG;
    if (prev >= 0 && q !== prev) sw++; prev = q;
    if (!started && buf >= START) { started = true; startup = t; }
    if (buf > MAXBUF) { t += buf - MAXBUF; buf = MAXBUF; }   // buffer full: wait, keep playing
  }
  console.log(name.padEnd(11) + (kb / (SEGS * SEG)).toFixed(0).padStart(8) + startup.toFixed(2).padStart(9) +
    String(stalls).padStart(7) + stallT.toFixed(1).padStart(9) + String(sw).padStart(9));
}
console.log(`trace kbps: min ${Math.min(...trace)}, max ${Math.max(...trace)}, mean ${(trace.reduce((a, b) => a + b) / SEGS).toFixed(0)}`);
console.log("rule       avg_kbps  start_s  stalls  stall_s  switches");
play("throughput", throughputRule); play("buffer", bufferRule);
play("fixed 720p", () => 3); play("fixed 240p", () => 0);

trace kbps: min 197, max 5545, mean 2358
rule       avg_kbps  start_s  stalls  stall_s  switches
throughput     1255     1.57      0      0.0       35
buffer         2028     1.57      5     20.5       67
fixed 720p     2768     1.57     70    559.0        1
fixed 240p      400     1.57      0      0.0        0

এবার সিস্টেমের দিক থেকে — player কোন সার্ভারে কী চায়, মান কখন বদলায়। নিয়ম আরও সরল: শেষ segment-এর মাপা গতি × ০.৮-এর মধ্যে সর্বোচ্চ মান; ladder ৪০০, ৮০০, ১,৪০০, ২,৮০০, ৫,০০০ kbps.

দেখার অভিজ্ঞতা — QoE — মাপা হয় শুরুর দেরি (p50, p95), rebuffer ratio, গড় bitrate, মান বদল আর শুরুই না হওয়ার হার দিয়ে; আসে player-এর ঘটনা থেকে, দেশ, ISP, যন্ত্র আর CDN ধরে ভাগ করে। সার্ভারের CPU দেখে দর্শকের কষ্ট বোঝা যায় না (পর্ব ৫০)।

৮ · গভীরে ঘ — বিতরণ: CDN, long tail, egress, সুরক্ষা আর view count

জনপ্রিয় বনাম long tail

CDN-এর মূল অঙ্ক পর্ব ১৭-এর অংশ ৫–৬-এ: origin-এর ভার = মোট × (১ − hit ratio), origin shield বহু edge-miss এক করে, আর hit ratio আসে Zipf-ধাঁচের জনপ্রিয়তা থেকে। ভিডিওতে বিশেষ দুটি কথা: এখানে byte hit ratio-ই আসল (অংশ ২-এর ৪৬.৯ Gbit/s সেখান থেকে); আর catalogue বিশাল — ভাইরাল নাটক সব edge-এ গরম, তিন বছর আগের রান্নার ভিডিও দিনে হয়তো দুবার, প্রতিবার miss; যেন চালু জিনিস প্রতিটি খুচরা দোকানে, কম চলা জিনিস শুধু পাইকারি আড়তে।

নিচে একটি edge-এর byte-ভিত্তিক LRU cache; ১,০০,০০০টি ভিডিও, Zipf α = ০.৯ (ধরা যাক), প্রতিটির জনপ্রিয় অংশ রাখতে ৫০–৫০০ MB. শেষ দুই সারিতে pre-positioning: সবচেয়ে জনপ্রিয়গুলো আগেই, রাতে, edge-এ বসিয়ে স্থির রাখা:

// One CDN edge, byte-capacity LRU, Zipf-like video popularity. Seeded: same output every run.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const TITLES = 100000, ALPHA = 0.9, WARM = 100000, REQS = 300000, EDGE_GBPS = 100;  // ASSUMED
const rnd = mulberry32(59), size = new Float64Array(TITLES + 1), cdf = new Float64Array(TITLES);
let sum = 0;                                     // GB an edge must hold to serve a title's views
for (let k = 1; k <= TITLES; k++) { size[k] = 0.05 + 0.45 * rnd(); sum += 1 / Math.pow(k, ALPHA); cdf[k - 1] = sum; }
const reqs = Array.from({ length: WARM + REQS }, () => {            // same request stream for all
  let lo = 0, hi = TITLES - 1; const x = rnd() * sum;
  while (lo < hi) { const m = (lo + hi) >> 1; if (cdf[m] < x) lo = m + 1; else hi = m; } return lo + 1; });
function edge(capGB, pinned) {                   // pinned: top titles pre-positioned, never evicted
  const lru = new Map(), pin = new Set(); let used = 0, hit = 0, n = 0, hitB = 0, allB = 0;
  for (let k = 1; k <= TITLES && pinned; k++) { if (used + size[k] > capGB) break; pin.add(k); used += size[k]; }
  reqs.forEach((k, i) => {
    const counted = i >= WARM, isHit = pin.has(k) || lru.has(k);
    if (counted) { n++; allB += size[k]; if (isHit) { hit++; hitB += size[k]; } }
    if (pin.has(k)) return;
    if (lru.has(k)) { lru.delete(k); lru.set(k, 1); return; }
    lru.set(k, 1); used += size[k];
    for (const [old] of lru) { if (used <= capGB) break; lru.delete(old); used -= size[old]; }
  });
  const bhr = hitB / allB;
  console.log(String(capGB / 1000).padStart(6) + (pinned ? "  pinned " : "  LRU    ") + (100 * hit / n).toFixed(1).padStart(8) +
    (100 * bhr).toFixed(1).padStart(10) + (EDGE_GBPS * (1 - bhr)).toFixed(1).padStart(12));
}
console.log(`catalogue ${TITLES} titles, ${(size.reduce((a, b) => a + b) / 1000).toFixed(1)} TB, Zipf alpha ${ALPHA}`);
console.log("cap_TB  policy   req_hit%  byte_hit%  origin_Gbps");
for (const cap of [500, 2000, 8000, 20000]) edge(cap, false);
edge(2000, true); edge(8000, true);

catalogue 100000 titles, 27.5 TB, Zipf alpha 0.9
cap_TB  policy   req_hit%  byte_hit%  origin_Gbps
   0.5  LRU        40.5      38.4        61.6
     2  LRU        56.5      55.0        45.0
     8  LRU        77.0      76.2        23.8
    20  LRU        87.8      87.4        12.6
     2  pinned     67.3      66.3        33.7
     8  pinned     83.5      83.0        17.0

নকশা-সিদ্ধান্ত চারটি: (১) segment-এর দীর্ঘ TTL আর revision-সহ path — purge প্রায় লাগে না; (২) অঞ্চলপ্রতি একটি shield — long tail-এর miss একবারই origin-এ, আর নতুন ভাইরাল ভিডিওর প্রথম ভিড় request collapsing-এ এক; (৩) নতুন বা প্রচারিত ভিডিও রাতে edge-এ পাঠানো — cache warming, এক ধরনের push; (৪) খুব বড় সেবা ISP-র ভেতরেই cache বসায় (ভাবনার প্রশ্ন ৪)।

কে দেখতে পারবেন — signed URL আর DRM, ধারণার স্তরে

সদস্যদের বা অঞ্চল-সীমিত ভিডিওর সুরক্ষা কয়েক স্তরে, প্রতিটি আলাদা জিনিস রক্ষা করে:

• Signed URL বা signed cookie (CDN-এ): playback API অনুমতি দেখে একটি সই করা token দেয় — path prefix (/v42/) আর মেয়াদ; edge প্রতিটি অনুরোধে database ছাড়াই সই আর মেয়াদ মেলায় (HMAC-ধাঁচ, পর্ব ২৬-এর presigned URL-এর চিন্তা)। ঠেকায় “লিংক পেলেই চিরকাল দেখা”, কিন্তু মেয়াদের মধ্যে ভাগ করা নয়।
• DRM: segment একটি content key-তে এনক্রিপ্ট; key দেয় আলাদা license server, শুধু অনুমতিপ্রাপ্ত player-কে, নিয়মসহ (মেয়াদ, যন্ত্র)। ব্রাউজারে মান-রূপ W3C-র Encrypted Media Extensions (২০১৭ সালে Recommendation), আর একই segment কয়েকটি DRM-এ চালাতে Common Encryption. DRM কপি কঠিন করে, অসম্ভব নয় — পর্দা রেকর্ড ঠেকানো যায় না।
• ভেতরের সুরক্ষা: bucket private, শুধু CDN-এর পরিচয়ে origin পড়া; key-গুলো envelope encryption-এ (পর্ব ৫২)।

View count — stream থেকে, আনুমানিক আর একটু দেরিতে

সবচেয়ে সরল নকশা — প্রতিটি দেখায় UPDATE videos SET views = views + 1 — একটি ভাইরাল ভিডিওতে ভেঙে পড়ে: মিনিটে ৫০,০০০ দেখা মানে একটি সারিতে সেকেন্ডে প্রায় ৮৩৩টি লেখা, প্রতিটি একই lock-এর জন্য লাইনে (পর্ব ২৪)। বদলে:

1. ঘটনা, গণনা নয়: player batch-এ ঘটনা পাঠায় (অংশ ৩); ingest সেগুলো log-ভিত্তিক stream-এ লেখে, partition key video_id — এক ভিডিওর সব ঘটনা এক partition-এ, ক্রমসহ (পর্ব ৩৩)।
2. “একটি দেখা” কী, সেটি নিয়ম: ধরা যাক একই সেশনে অন্তত ৩০ সেকেন্ড চললে একটি view (সংজ্ঞা সেবাভেদে আলাদা); পুনরাবৃত্ত ঘটনা dedup window-এ বাদ, তাই at-least-once-এও হিসাব idempotent.
3. জানালা ধরে যোগ: প্রতি মিনিটের tumbling window-এ প্রতিটি ভিডিওর মোট counter store-এ একবার যোগ (পর্ব ৩৬) — ভাইরাল ভিডিওতেও মিনিটে একটি লেখা; খুব গরম key-তে sharded counter.
4. আনুমানিক কাঠামো: আলাদা দর্শক — HyperLogLog, কয়েক KB-তে; এই ঘণ্টার ভাইরাল — count-min sketch আর heap দিয়ে top-k (পর্ব ৪৫)।
5. দেখানো: গণনা cache থেকে, মিনিটখানেক পুরোনো হলেও চলে। জাল দেখা বাছাই পরে চলতে পারে, তাই গণনা পরে সংশোধিতও হয়; নির্মাতার আয়ের হিসাব হলে আলাদা, নিরীক্ষাযোগ্য batch.

Metadata, search আর ঠান্ডা ভিডিও

Search: metadata-র প্রতিটি বদল outbox বা CDC দিয়ে indexer-এ যায়, যা inverted index হালনাগাদ করে (পর্ব ২৭); index-এ শুধু ready আর public ভিডিও, আর private করা ভিডিও দ্রুত সরাতে হয় — দেরি মানে গোপনীয়তার ঝুঁকি। ঠান্ডা ভিডিও: আসল ফাইল ladder-এর প্রায় তিন-চতুর্থাংশ জায়গা নেয়, অথচ প্রক্রিয়ার পরে কদাচিৎ লাগে — lifecycle নিয়মে archive storage class-এ (পর্ব ২৬)। প্রায় না-দেখা ভিডিওর ওপরের মান cool স্তরে, বা মুছে দরকারে আবার encode — দাম: হঠাৎ জনপ্রিয় হলে প্রথম দর্শকেরা কিছুক্ষণ নিচু মান পাবেন।

৯ · ভাঙন, trade-off আর বিস্তার — কী ভাঙতে পারে, ১০ গুণে কী হবে

১০ গুণে কোথায় ভাঙবে? Peak egress প্রায় ৯.৪ Tbit/s — প্রথম সীমা CDN-এর ক্ষমতা আর বিল (বেশি edge, ISP-র ভেতরে cache, ভালো codec); transcoding বছরে ৭৩ লাখ ঘণ্টা (নতুন codec শুধু জনপ্রিয় ভিডিওতে); metadata-য় video_id ধরে আরও shard; view events-এ আরও partition আর client-এ বড় batch.

নজরদারি — কী নিয়ে alert: rebuffer ratio আর শুরুর দেরির p95 (দেশ, ISP, CDN ধরে); playback শুরু না হওয়ার হার; byte hit ratio আর origin egress; আপলোড ব্যর্থতা; “processing”-এ আটকে থাকা ভিডিওর বয়স; transcoding queue-র গভীরতা; view stream-এর consumer lag. SLO বসান দর্শকের অভিজ্ঞতায় (পর্ব ৫০)।

অপব্যবহার, প্রতিরক্ষার দিক থেকে: আপলোডে quota আর rate limit (পর্ব ৪৯); প্রতি token-এ যুক্তিসংগত segment-হার, যাতে কেউ পুরো catalogue টেনে নিতে না পারেন; প্রকাশের আগে বিষয়বস্তু যাচাই; লগে token আর সই করা URL-এর query string নয়।

Live streaming বিস্তার: পুরো ভিডিও আগে থেকে নেই, তাই টুকরো করে encode চলে না — প্রতিটি মান real time-এর চেয়ে দ্রুত encode হতে হয়, manifest প্রতি কয়েক সেকেন্ডে বদলায়; দেরি কমাতে Low-Latency HLS. বিস্তার ভাবনার প্রশ্ন ১-এ আর CN কোর্সের অংশ ৯-এ।

১০ · AI-এর যুগে — AI-এর ভিডিও-নকশা যাচাই

একটি ভিডিও প্ল্যাটফর্মের নকশা চাইলে AI কয়েক সেকেন্ডে বাক্স-তীরের খসড়া দেয় — প্রায়ই “S3 + Kafka + Redis + microservices” একসাথে। ভুল ধরা পড়ে সংখ্যায় আর ব্যর্থতার প্রশ্নে:

AI-এর ভিডিও-নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Storage, peak egress আর origin traffic নিজে আবার হিসাব করেছি — একক (bit, byte, Mbit/s, Gbit/s) মিলিয়ে
• ভিডিওর বাইট API server দিয়ে যায় না; আপলোড resumable, checksum দুই স্তরে, completion event outbox-এ
• Transcoding-এর কাজ idempotent, lease-সহ, সীমিত retry আর DLQ; অঙ্কে সবচেয়ে লম্বা কাজ আর বাড়তি খরচ আছে
• Segment-এর সীমানা সব মানে এক; segment-এর TTL দীর্ঘ, path-এ revision; shield আর long tail-এর হিসাব আছে
• View count-এ প্রতি দেখায় একটি UPDATE নেই; “একটি view”-এর সংজ্ঞা, dedup আর দেরি লেখা আছে
• দাম আর সীমা নথিতে মিলিয়েছি; একটি ছোট simulation বা load test আর CDN, origin, queue ও region ধরে failure-mode review করেছি