Chapter 14 · Hinglish · Sunne-wala Sabak

Design YouTube — Video Platform

Ek planet-scale video service kaise banta hai — upload se lekar adaptive streaming, storage tiers, aur global CDN tak. Niche "Play all" dabaiye aur browser pura chapter padh kar sunayega. Kisi bhi section par "Suniye" se wahin se shuru karein.

Companion slides kholiye
Bhasha Hinglish (Roman) Sunne ka tareeka browser text-to-speech English version visual lesson →
🔊 Suniye Voice Speed

Tip: jo voice sabse natural lage wahi chuniye — ek Hindi (hi-IN) ya Indian-English (en-IN) voice aam taur par best chalti hai.

Kya bana rahe hain Slide 2

Chalo chapter chaudah shuru karte hain, design YouTube. Sabse pehli baat samajh lo, yeh system read-heavy hai. Kuch hi creators bade bade video files upload karte hain, par arbon viewers chhote chhote chunks wapas padhte hain. Isliye poora design reads ki taraf jhukta hai. Ek yaad rakhne wala number, reads writes se lagbhag sau guna zyada hote hain. Yahi ek baat decide karti hai ki read path ko CDN milega aur write path ko ek factory. Functional requirements chhoti hain, upload karo aur kisi bhi device par dekho. Asli mushkil non-functional hai, jaise playback do second se kam mein shuru ho, aur ek important rule, agar comments ya search neeche chala jaaye to bhi video chalta rehna chahiye.

Kitna bada hai Slide 3

Ab thoda back of the envelope. Ingest, yaani roz kitna raw video andar aata hai, petabytes mein hota hai. Par asli chaunkane wala number egress ka hai, yaani edge se roz kitne bytes bahar jaate hain. Yeh itna zyada hai ki origin se kabhi serve ho hi nahi sakta. Isliye ek high hit ratio wala CDN yahan optional nahi hai, wahi ekmatra tareeka hai jisse maths sahi baithta hai. Do baatein yaad rakho. Ek, storage hours of video ke saath badhta hai aur kabhi ghatta nahi, isliye purane bytes ko saste tiers mein khiskana padta hai. Do, egress itna bada hai ki lagbhag pachanve percent se zyada bytes edge se hi aane chahiye.

BLOB PLANE — pixels Upload Transcoder Renditions Global CDN CONTROL PLANE — facts Metadata API Metadata DB jod sirf ek object key se
Do planes — upar pixels, neeche facts — sirf ek key se jude.

Do planes ka design Slide 4

Poore system ko do alag lanes ki tarah socho. Pehla, blob plane, yeh video factory hai. Ek upload raw master banata hai, transcoder usse kai renditions mein todta hai, aur CDN unhe viewers tak pahunchata hai. Doosra, control plane, yeh ek normal web backend hai. Ek API jo metadata database ke upar chalti hai, aur counts ke liye ek async pipeline. In dono ko jodne wali cheez sirf ek key hai. Metadata ki row mein object ka path hota hai, kabhi bhi asli bytes nahi. Isse dono planes apni apni speed par scale aur fail ho sakte hain.

Upload flow Slide 5

Ek ghante ka high resolution video gigabytes ka hota hai, aur woh flaky Wi-Fi par chalta hai. Isliye upload ko ek bade daav ki tarah mat socho, balki chhote chhote commitments ki tarah. Client file ko chhote parts mein todta hai, har part seedha object storage mein bhejta hai, aur agar koi failure ho to poochta hai, kaun se offsets pahunch gaye, aur sirf missing parts dobara bhejta hai. Har part ek uploadId aur part number se keyed hota hai, isliye dobara bhejna nuksaandeh nahi hai, kyunki wahi part bilkul waisa hi overwrite ho jaata hai. Aur final commit ek atomic step hai, isliye agar client timeout ke baad retry kare to bhi do video ya aadha video nahi banta.

Transcoding ek DAG hai Slide 6

Master ko pehle probe kiya jaata hai, phir chunks mein toda jaata hai, aur phir kai encoders mein fan out kiya jaata hai jo parallel chalte hain, har resolution aur codec ke liye ek. Saath mein thumbnails aur captions ke side jobs bhi. Ek packager in outputs ko HLS aur DASH segments aur manifests mein wrap karta hai, aur aakhri step ready flag ko on karta hai. Ise ek DAG ki tarah socho, yaani chhote chhote pure jobs ka ek graph. Har node apne inputs ka function hai, isliye agar koi output kho jaaye to use bas dobara bana lo. Aur encoders horizontally scale karte hain.

Ek source, kai renditions Slide 7

Itni saari copies kyun banate hain. Kyunki ek naya phone fibre par aur ek purana tablet cafe ke Wi-Fi par ek hi file use nahi kar sakte. Transcoder ek bitrate ladder banata hai, yaani wahi content badhti resolutions aur bitrates par, kai codecs mein. Player wahi rung uthata hai jo abhi afford kar sake. Naye codecs purane codec ke muqable lagbhag tees se pachaas percent kam bytes lete hain, par decode karne mein zyada CPU maangte hain. Isliye kai codecs bhejte hain, taaki har device apna best trade-off chun sake. Ek important baat, renditions derived data hain, unhe hamesha master se dobara banaya ja sakta hai.

Hot, warm, cold, archive Slide 8

Bahut chhota sa hissa videos ka apne pehle hafte mein lagbhag saare views le leta hai. Baaki sab long tail ban jaata hai, kabhi kabhi dekha jaata hai par hamesha ke liye rakha jaata hai. Cost tabhi sambhalti hai jab bytes apne access pattern ke saath chalein. Hot tier edge par SSD aur RAM mein hota hai, trending videos ke liye. Warm tier regional object store hai. Cold tier multi region aur erasure coded hai, long tail ke liye. Aur archive deep storage hai, masters ke liye. Ek frequency tracker objects ko tiers ke beech promote aur demote karta hai, aur yeh sab async hota hai, isliye viewer kabhi block nahi hota. Master top-tier durability par archive mein rehta hai.

HLS aur DASH Slide 9

Hum ek bada file kabhi stream nahi karte. Har rendition ko chhote segments mein kaata jaata hai, lagbhag do se chhah second ke, aur ek manifest player ko batata hai ki har segment kahan hai. Ek master manifest available renditions ki list deta hai, aur har rendition ki apni playlist hoti hai jismein segment URLs hote hain. Yeh sab bas plain HTTP GET hai, static objects ke. Isliye yeh har layer par aasani se cache hota hai aur maujooda CDN machinery par muft mein chalta hai. HLS aur DASH mein bas syntax ka farak hai, shape ek hi hai, isliye ek modern packager dono ek saath nikalta hai.

Adaptive bitrate selection Slide 10

Quality server nahi chunta, device chunti hai, har segment ke hisaab se. Server bas menu dikhata hai, yaani manifest, aur client wahi order karta hai jo abhi fit baithe. Yeh jaan boojh kar aisa hai, kyunki sirf device ko real time radio strength, congestion aur throttling dikhti hai, aur wahi ek hi segment ke andar react kar sakti hai. Player har segment ka download time naapta hai aur ek rolling bandwidth estimate banata hai. Woh apna playback buffer bhi dekhta hai, agar buffer khaali hone lage to quality turant giraa deta hai. Aur woh thoda hysteresis jodta hai, taaki har chhoti wobble par upar neeche na flap kare. Smoothness zyada zaroori hai bajaye last bit ke peeche bhaagne ke.

CDN ki teen layers Slide 11

Ek teen layer wali cache hierarchy bytes ko har viewer se seconds ki doori par rakhti hai, aur saath hi origin ko bheed se bachati hai. Viewer paas ke ek edge POP par jaata hai. Agar edge par miss ho to edge ek regional origin shield se maangta hai. Aur sirf tab jab shield bhi miss kare, tab origin ko chhua jaata hai. Shield ka kaam hai request collapsing. Jab koi video viral hota hai, to ek hi segment ke liye hazaar edge misses milkar sirf ek origin fetch ban jaate hain. Isliye ek viral video kabhi origin ko stampede nahi karta. Lagbhag pachanve percent se zyada bytes edge par hi serve ho jaate hain.

Metadata aur blobs alag rehte hain Slide 12

Titles, comments, subscriptions aur view counts chhote hote hain aur rich queries se padhe jaate hain. Video bytes bahut bade hote hain aur sirf primary key se padhe jaate hain. In dono ko milaana database crash karne ka sabse tez tareeka hai. Isliye metadata plane ek indexed, transactional, cached store hai, jaise pichle chapters ka key value ya sharded SQL pattern. Aur blob plane flat, immutable, sirf key se access hone wala object storage hai. Dono ke beech link bas ek path string hai. Isse failure isolation muft mein milti hai. Metadata down ho to shayad title chhup jaaye, par CDN har chalte hue video ko segments deta rehta hai.

View counts async hote hain Slide 13

Ek trending video ek minute mein laakhon plays le sakta hai. Har view ke liye ek row relational table mein likhna database ko jalaa dega, aur yeh model waise bhi galat hai. Counts eventually consistent metrics hain, transactions nahi. Play events ek log se hokar ek real time aggregator mein jaate hain, jo ek fast approximate live counter ko feed karta hai. Saath hi ek dheema batch reconciler authoritative number dobara nikalta hai, bots aur duplicates hata kar. UI live counter dikhata hai taaki snappy lage, aur batch path baad mein sachchi ginti theek kar deta hai. Do paths, do speeds.

Aage kya Slide 14

To chhah principles yaad rakho. Ek, byte plane aur control plane ko alag rakho, key se jodo, join se nahi. Do, bhaari kaam ko chhote retryable jobs ke DAG ki tarah socho. Teen, intelligence ko edges par bhejo, CDN bytes leta hai aur player quality chunta hai. Chaar, bytes ko unke access pattern ke saath chalao. Paanch, counts streams hain, transactions nahi. Aur chhah, koi bhi component fail ho to video ko saath mat le jaane do. Ek kaam karo, apne pasand ke kisi video app ka ek watch loud bolkar trace karo, edge se shield se origin tak. Koi cheez atke to mujhse pooch lena. Agla chapter, design Google Drive.