Chapter 1 · Hinglish · Sunne-wala Sabak
Ek User Se Millions Tak
System design ka pehla sabak — Hinglish mein, padhne aur sunne ke liye. Niche "Play all" dabaiye aur browser aapko pura chapter padh kar sunayega. Kisi bhi section par "Suniye" se wahin se shuru karein.
▶ Companion slides kholेंTip: jo voice sabse natural lage wahi chuniye — ek Hindi (hi-IN) ya Indian-English (en-IN) voice aam taur par best chalti hai. Voices har device par alag hoti hain.
Shuru karne se pehle Slide 1
Chalo shuru karte hain. System design ka pehla aur sabse zaroori idea bahut simple hai. Aap din ek se hi millions users ke liye design nahi karte. Aap ek single server se shuru karte ho, aur jaise jaise load badhta hai, ek ek karke problem solve karte ho. Har naya layer pichle layer ki ek specific problem ko theek karta hai. Is chapter mein hum wahi seedhi, yaani ladder, ek ek rung chadhenge. Niche ka diagram dikhata hai ki aakhir mein system kaisa banta hai. Ise abhi yaad karne ki zaroorat nahi, hum ise tukdo mein khud banayenge.
Pura raasta — ek nazar mein Slide 2
Sabse pehle pura raasta dekh lete hain. Baarah moves hain jo aapko ek chhote project se ek internet-scale system tak le jaate hain. Har step ka ek hi rule hai. Jab tak koi cheez actually break na ho, naya layer mat add karo. Metrics dekho, yaani latency, error rate, aur queue depth, aur tabhi agla kadam uthao. Aage hum har rung ko ek ek karke samajhenge.
1 · Ek hi box se shuruaat Slide 3
Pehla step. Sab kuch ek hi box par. Web app, database, static files, sab ek single server par chalte hain. User ka browser DNS se aapke server ka IP nikaalta hai aur seedha HTTP se baat karta hai. Yeh sabse fast hai ship karne ke liye, sabse sasta hai, aur debug karna sabse aasaan. Problem tab aati hai jab ek hi process saara CPU ya memory kha jaata hai aur poori site down ho jaati hai. Yaad rakho, shuruaat hamesha sabse simple cheez se karo jo kaam kar sake.
2 · Sahi database chunna Slide 4
Doosra step, sahi database chunna. Yeh pehla aisa decision hai jise badalna mushkil hai. SQL, jaise Postgres ya MySQL, tab choose karo jab aapko transactions, joins, aur strong consistency chahiye. NoSQL, jaise DynamoDB ya Cassandra, tab jab schema flexible ho ya writes bahut zyada ho. Sach baat yeh hai ki pehle ek million users tak ek managed Postgres almost hamesha jeet jaata hai. NoSQL un problems ko solve karta hai jo zyadatar apps ko kabhi aati hi nahi.
3 · Vertical vs Horizontal Slide 5
Teesra step, scaling ke do tareeke. Vertical scaling matlab box ko bada karna, zyada CPU aur zyada RAM. Isme code nahi badalna padta, par ek limit ke baad yeh ruk jaata hai, aur single failure abhi bhi aapko maar sakta hai. Horizontal scaling matlab zyada identical servers add karna, ek load balancer ke peeche. Iske liye app ka stateless hona zaroori hai. Rule simple hai. Vertical se shuru karo kyunki woh free hai, aur horizontal par tab jao jab availability simplicity se zyada important ho jaaye.
4 · Load balancer Slide 6
Chautha step, load balancer. Yeh ek traffic director hai jo web tier ke aage baithta hai. Public ko sirf ek IP dikhta hai, aur peeche kai servers kaam baant lete hain. Load balancer har server ko health check karta hai. Agar koi server jawab dena band kare, traffic apne aap doosre par chala jaata hai, aur user ko pata bhi nahi chalta. Ek bonus bhi hai. Sirf load balancer ke paas public IP hota hai, baaki servers ek private network par chhupe rehte hain, jo ek security win hai.
5 · Database replication Slide 7
Paanchva step, database replication. Jab web tier redundant ho gaya, ab database single point of failure ban jaata hai. Ek primary saare writes handle karta hai, aur replicas uska data copy karke reads serve karte hain. Zyadatar systems read-heavy hote hain, isliye yeh achha scale karta hai. Ek dhyaan ki baat hai, replication lag. Replicas thode seconds peeche hote hain, isliye abhi post kiya aur abhi dikhao wale case mein us read ko primary se padhna padta hai.
6 · Caching Slide 8
Chhatha step, caching. Memory disk se lagbhag ek lakh guna fast hoti hai. Cache hot data ko database ke aage rakhta hai, taaki zyadatar reads disk tak pahunche hi na. Pattern simple hai. Pehle cache check karo, hit ho to turant return karo, miss ho to DB se laao aur cache mein likh do. TTL theek rakhna, bahut lamba to data stale ho jaata hai, bahut chhota to cache bekaar ho jaata hai. Aur ek khatra hai, cache stampede, jab ek hot key expire hote hi hazaar requests ek saath usse rebuild karne lagti hain.
7 · CDN Slide 9
Saatva step, CDN, yaani content delivery network. Yeh static assets ke liye ek global cache hai. Images, CSS, JavaScript, aur videos, sab edge servers se serve hote hain jo user ke paas hote hain. Latency kam hone ki wajah physics hai. Light ki speed fixed hai. Mumbai se Frankfurt ek round trip kam se kam 150 milliseconds leta hai, par Mumbai se Mumbai ke edge tak sirf 10 milliseconds. Isliye data ko user ke kareeb le aao, kyunki light ko tez nahi kar sakte.
8 · Stateless web tier Slide 10
Aathva step, web tier ko stateless banao. Horizontal scaling tabhi kaam karta hai jab servers interchangeable ho. Sticky session ek trap hai. Agar user ka session server ek ki memory mein hai, to load balancer ko hamesha usi server par bhejna padega, aur woh server gaya to session gaya. Fix yeh hai ki session Redis mein daalo aur uploads object storage mein. Ab koi bhi request kisi bhi server par ja sakti hai. Aise servers cattle ban jaate hain, pets nahi.
9 · Multiple data centers Slide 11
Nauva step, multiple data centers. Ek poora region offline ho sakta hai, power jaaye, fibre kat jaaye, ya cloud provider down ho. GeoDNS har user ko sabse kareeb wale healthy data center par bhejta hai. Mushkil hissa data hai. Har data center ko apni copy chahiye, aur cross-region replication asynchronous hoti hai, isliye thoda lag accept karna padta hai. Aur jo failover plan kabhi test nahi hua, woh zaroorat ke waqt fail hoga, isliye drills chalao.
10 · Message queue Slide 12
Dasva step, message queue. Har kaam request ke andar khatam karna zaroori nahi. Queue producers aur consumers ko alag kar deti hai. Web server job queue par daal kar turant return ho jaata hai, aur workers usse jab free ho tab process karte hain. Yeh spikes ko absorb karti hai. Signup ki baadh email service ko crash nahi karti, emails queue ho kar ek steady rate par jaati hain. Aur dono sides alag alag scale hote hain, zyada processing matlab zyada workers, zyada traffic matlab zyada web servers.
11 · Logging, metrics, automation Slide 13
Gyaarahva step, logging, metrics, aur automation. Scale par aap box mein SSH karke problem nahi dhoondh sakte. Logs structured aur centralized hone chahiye, aur har request par ek trace ID hona chahiye. Metrics mein chaar golden signals dekho, yaani latency, traffic, errors, aur saturation. Alert user ko dikhne wale symptoms par karo, jaise p99 latency, na ki CPU 80 percent par. Aur jo kaam do baar haath se kiya, usse script kar do.
12 · Database sharding Slide 14
Baarahva step, database sharding. Jab primary database aur bada nahi ho sakta, to data ko kai databases mein baant dete hain. Ek shard key, jaise user_id modulo N, decide karta hai ki row kis shard par jaaye. Sahi key chunna hi sab kuch hai. Galat key se hot shards ban jaate hain, jahan ek hi DB saara kaam karta hai. Yeh aakhri option hai, pehla nahi. Pehle replicas, caching, aur bade box try karo, kyunki sharding ko wapas badalna bahut mushkil hai.
Asli principles Slide 15
Aakhir mein, yeh saari architectures sirf tools hain. Asli cheez yeh samajhna hai ki kaunsa tool kab uthana hai. Aane wali problem solve karo, future ki nahi. Statelessness ek superpower hai. Cache aggressively karo, par invalidate dhyaan se. Asynchrony failure ko alag karti hai. Jo dikhta nahi usse manage nahi kar sakte, isliye observability zaroori hai. Aur yaad rakho, failure normal hai. Har component kabhi bhi fail ho sakta hai, isliye design usi hisaab se karo.
Aage kya
Bas, yahi hai chapter ek ka nichod. Agar koi baat clear nahi hui, to mujhse poocho, main aapka teacher hoon. Aur ek kaam karo. Hero diagram mein se ek box uthao aur khud se bolo ki agar woh hata diya jaaye to kya break hoga. Yahi soch aapko interview mein le jaayegi. Agle chapter mein hum back-of-the-envelope estimation seekhenge.