Chapter 15 · Hinglish · Sunne-wala Sabak
Design Google Drive — File Sync ka Andar
File storage aur sync service kaise banta hai — bytes laptop se object store tak kaise jaate hain, ek edit har device tak kaise pahunchti hai, aur yeh sab bina baar baar wahi cheez upload kiye kaise hota hai. Niche "Play all" dabaiye aur browser pura chapter padh kar sunayega.
▶ Companion slides kholiyeTip: jo voice sabse natural lage wahi chuniye — ek Hindi (hi-IN) ya Indian-English (en-IN) voice aam taur par best chalti hai.
File service kya vaada karti hai Slide 2
Chalo chapter pandrah shuru karte hain, design Google Drive. Sabse pehle yeh socho ki ek file service user se kya vaada karti hai. Paanch cheezein. Ek, upload aur download, chhoti file se lekar badi video tak, aur flaky network par resumable. Do, sync across devices, laptop par edit karo to phone par seconds mein dikhe. Teen, sharing, link ya email se, roles ke saath. Chaar, version history, taaki kal ki galti se hui delete wapas la sako. Aur paanch, non-functional, yaani strong durability, eventual consistency, fast metadata reads, aur bandwidth-efficient sync. Asli design in non-functional requirements mein chhupa hai.
Do store, ek split Slide 3
Ab bird's-eye view. Sabse badi baat samajh lo, yahan do alag store hain, ek nahi. Ek object store jismein sirf anonymous bytes ke blocks rehte hain, aur ek metadata database jismein file ka naam, folder tree, version history, aur permissions rehte hain. File actually kya hai, sirf ek ordered list of block hashes jo metadata mein likhi hoti hai. Beech mein ek API gateway auth aur routing karta hai, ek sync service upload orchestrate karti hai aur diffs resolve karti hai, aur ek notification service change events baaki devices tak bhejti hai. Bytes aur metadata alag store mein isliye rehte hain taaki dono apni apni axis par scale kar saken.
File ko blocks mein kaato Slide 4
Ab chunking. Ek badi video ko ek hi blob ki tarah bhejna galti hai, kyunki timeout aur retry ki barbaadi hoti hai. Iske badle file ko chaar megabyte ke fixed-size blocks mein kaat do. Ab ek gigabyte ki file matlab do sau chhote uploads, jo parallel mein user ki poori uplink bhar dete hain. Agar ek block fail ho to sirf wahi block dobara bhejo, baaki sab nahi. Streaming bhi easy, pehle kuch blocks aate hi video chalne lagti hai. Har block ko hash karo, ek content hash banao, aur wahi hash us block ka address ban jaata hai, filename nahi.
Ek block, ek hi baar store Slide 5
Ab deduplication. Wahi PDF hazaaron inbox mein hai, wahi library laakhon repos mein. Same bytes ko sirf ek baar store hona chahiye. Trick simple hai. Block upload karne se pehle client use hash karta hai aur server se poochta hai, kya tumhare paas yeh hash pehle se hai. Agar haan, to bytes bhejna hi mat, bas nayi file ko us purane block par point kar do. Do layer hoti hain, per-user dedup aur global dedup across all tenants. Har block par ek reference count rehta hai. Jab aakhri file bhi delete ho jaaye to count zero, aur background garbage collection block ke bytes hata deta hai. Ek trade-off, agar privacy zaroori ho to log cross-tenant dedup band kar dete hain, kyunki upload timing se pata chal sakta hai ki koi file pehle se maujood hai.
Sirf jo badla wahi upload karo Slide 6
Ab delta sync. Socho ek user do sau page ke document mein ek paragraph badalta hai aur save dabata hai. Naive sync poori file dobara bhejti hai. Delta-aware sync sirf ek block bhejti hai, same correctness par lagbhag poora bandwidth bach jaata hai. Client kaise decide karta hai. Pehle local file ko dobara chunk aur hash karo. Phir apni hash list ko server ki hash list se compare karo. Phir sirf wahi hashes upload karo jo server ke paas nahi hain. Aur aakhir mein un blocks par ek naya file pointer commit karo. Delta sync basically dedup hi hai, ek hi file ke versions ke beech, unchanged blocks reference hote hain, sirf badla hua block travel karta hai.
Metadata DB mein file rehti hai Slide 7
Ab metadata database. Object store ke blocks to bas anonymous bytes hain, unka koi naam ya owner nahi. Metadata DB inhe file banati hai. Chaar tables. Files table mein naam, owner, parent folder, aur current version ka pointer. Versions table append-only hai, har row ek immutable ordered list of block hashes, yaani us version ko banane ki recipe. Blocks table content-addressed hai, block hash primary key, aur reference count jo garbage collection chalata hai. Aur permissions table, kaun kya kar sakta hai. Ek practical baat, files aur versions ko owner id par shard karo taaki ek user ka poora tree ek hi shard par rahe aur folder listing ek fast read ho. Blocks table global hai, use block hash prefix par shard karo.
Content se keyed object store Slide 8
Ab block storage khud. Bytes kabhi relational database ko nahi chhoote, woh object store mein jaate hain, jaise cloud ka object store, jahan key ek path nahi balki content ka hash hai. Content-addressing se teen cheezein muft milti hain. Ek, dedup, do same blocks ek hi key par, doosra write no-op. Do, tamper-evident, read par dobara hash karo, agar match na kare to woh replica corrupt hai aur system doosri good copy padh leta hai. Teen, cache-friendly, hash hi etag hai, isliye CDN aur client hamesha ke liye cache kar sakte hain. Aur cost ke liye tiering, hot blocks SSD par, warm HDD par, cold tape par. Durability ke liye teen replicas alag availability zones mein, aur cold data ke liye erasure coding jo sasti padti hai.
Har device ko turant batao Slide 9
Ab notifications. Upload tab tak khatam nahi jab tak user ke phone, tablet, aur doosre laptop ko bhi pata na chal jaaye. Notification service change event ko har subscribed device tak fan-out karti hai. Par ek gehri baat samajh lo. Push sirf ek optimisation hai. Har client ek monotonic sync cursor rakhta hai aur reconnect par bas poochta hai, mere cursor ke baad kya kya badla. Yahi cursor sync ko sahi banata hai, push nahi. Jo device offline tha aur push miss kar gaya, woh reconnect par cursor aage badha kar sab kuch pakad leta hai. Real-time ke liye WebSocket ya SSE better hai, aur long-polling universal fallback hai jo NAT aur firewall ke peeche bhi chalta hai.
Immutable blocks, mutable pointers Slide 10
Ab versioning. Ek rule maan lo, blocks kabhi badalte nahi. Naya version bas ek nayi ordered list of block hashes hai, purane versions apne purane blocks par point karte rehte hain. Block teen ko edit karne par ek naya block banta hai aur purana block waisa hi rehta hai, isliye version ek aur do dono saath saath jeevit rehte hain aur common blocks share karte hain. Isse teen faayde. Ek, versions sasta ho jaata hai kyunki sirf delta store hota hai. Do, time travel ek pointer flip hai, restore karne par sirf current version ka pointer purane version id par set karo, koi bytes move nahi hote. Teen, deletes safe hain, reference count kam hota hai aur block tabhi jaata hai jab truly orphan ho. Rename sirf naam badalta hai, move sirf parent id, bytes untouched.
Jab do device ek file edit karein Slide 11
Ab conflicts. Do laptop offline gaye, dono ne ek hi file edit ki, dono reconnect hue. Pehle detection. Har upload apne saath parent version id le kar aata hai, yaani woh kis version par bana tha. Agar client version do ke upar commit karne aaye par server pehle hi aage badh chuka hai, to server ko pata chal jaata hai ki client ka parent stale hai. Yahi conflict ka trigger hai. Ab do strategies. Last-write-wins, jo aakhir mein aaye wahi current, haarne wale ki edit history mein rehti hai par live file nahi rehti. Ya keep-both, jismein server choose karne ke badle ek conflicted copy bana deta hai alag naam se, taaki koi edit chupke se gum na ho. Real-time collaborative editing ek alag problem hai, ek layer upar, jahan har keystroke ek operation hoti hai jo concurrent operations ke against transform hoti hai.
Sharing aur permissions Slide 12
Ab sharing aur permissions, sabse subtle correctness problem. Ek galat row private data leak kar deti hai, aur ek over-eager cache stale private data leak kar deti hai. Do share modes hain. Per-principal, jaise Bob is folder ko edit kar sakta hai, ek row permissions table mein. Aur link-based, jaise is URL wale koi bhi dekh sakte hain, jismein ek lamba unguessable token hota hai jise server lookup karta hai, aur revoke karne par token rotate ho jaata hai. Roles ka smallest set, viewer, commenter, editor, owner. Folder grants neeche cascade hote hain, aur child par explicit grant sirf widen kar sakta hai, narrow nahi. Aur har request par ek check chalta hai, file se parent se root tak walk karo, applicable grants collect karo, highest role lo, aur dekho role action ko cover karta hai ya deny. Isse hot rakhne ke liye ek denormalised effective ACL cache karte hain.
Chhah principles Slide 13
To chhah principles yaad rakho. Ek, bytes aur metadata ko alag karo, object store aur database apni apni axis par scale karte hain. Do, pehle chunk karo phir hamesha hash karo, fixed-size blocks aur content-addressing ek mushkil transfer ko kai aasaan bana dete hain. Teen, jo bytes bacha sako bachao, dedup, delta sync, aur pointer flips fizool copy hatate hain. Chaar, blocks ko immutable banao, isse sasta versioning, safe deletes, aur bullet-proof caching milta hai. Paanch, cursors correctness hain aur push sirf speed, har client reconnect par cursor se converge karta hai. Aur chhah, apni conflict policy pehle se decide karo, last-write-wins simple hai par kaam chhupa sakti hai, keep-both safe hai par shor zyada.
Aage kya
Bas, yahi hai chapter pandrah. Ek kaam karo, apne dimaag mein ek file ke ek block ka edit trace karo. Client kya upload karta hai, metadata mein kaunsi nayi rows aati hain, aur kaunse reference counts badalte hain. Phir ulta socho, restore dabane par kya move hota hai aur woh lagbhag muft kyun hai. Yeh do flows samajh gaye to poora Google Drive samajh mein aa gaya. Koi bhi cheez confuse kare to mujhse pooch lena. Agla chapter patterns aur lessons ka hai, jahan hum in saare chapters ke common ideas ek saath dekhenge.