Chapter 16 · Hinglish · Sunne-wala Sabak
Patterns & Lessons — Poori Series Ka Nichod
Pandrah chapters ke baad wahi shapes baar baar lautkar aati hain. Niche "Play all" dabaiye aur browser pura chapter padh kar sunayega. Kisi bhi section par "Suniye" se wahin se shuru karein.
▶ 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.
Yeh finale chapter hai Slide 1
Chalo aakhri chapter shuru karte hain, patterns aur lessons. Yeh koi nayi system design nahi hai, yeh ek step back hai. Pandrah chapters mein humne newsfeed, chat, crawler, aur storage banaye, aur baar baar wahi shapes lautkar aayi. System design ka asli kaam invention nahi, selection hai. Ek chhoti si vocabulary of components aur patterns lagbhag har problem cover kar leti hai. Skill sirf itni hai, ki sahi shape pehchano, honestly chuno, aur uski cost ko naam do.
Chhah pieces ka toolkit Slide 2
Pehle toolkit. Lagbhag har design chhah pieces mein se kuch use karti hai. Load balancer requests ko spread karta hai aur dead nodes ko ek stable endpoint ke peeche chhupa deta hai. Cache computed answer ko read ke paas rakhta hai. Queue producer aur consumer ke beech kaam buffer karti hai. Database source of truth hai. CDN bytes ko user ke paas edge se serve karta hai. Aur blob store bade write-once objects ke liye sasta durable storage hai. Yaad rakho, product yaad karne se zyada zaroori hai role samajhna. Aur ek habit dhyaan do, blob store ko aam taur par CDN chahiye, database ko cache chahiye, aur queue ko ek dead-letter queue chahiye.
Stateless hokar scale-out karo Slide 3
Pehla pattern, outward scale karo aur servers ko stateless rakho. Vertical scaling, yaani bada box, tab tak aasan hai jab tak ceiling nahi aata. Horizontal scaling elasticity aur rolling deploys deta hai, par tabhi jab koi request kisi ek box se chipki na ho. Iska trick hai, saara session state app tier se bahar nikaal do, taaki koi bhi server koi bhi request serve kar sake. Do baatein zaroori hain. Ek, handlers ko idempotent banao, taaki load balancer ka retry card ko do baar charge na kare. Do, shared dependency par nazar rakho, kyunki agar har stateless box ek hi database ko hammer kare, to bottleneck sirf ek hop aage khisak gaya, khatam nahi hua.
Cache everywhere Slide 4
Doosra pattern, cache har jagah lagao, par asli mushkil hai use kab phenkna. Browser cache karta hai, CDN cache karta hai, app server cache karta hai, database cache karta hai. Har layer latency se ek zero kaat deti hai. Par ek cache sirf ek bet hai ki value abhi bhi sachchi hai. To ek hi sawaal sab decide karta hai, cached value kab sachchi rehni band ho jaati hai. Iske teen tools hain. TTL sabse lazy default hai. Explicit delete on write zyada sharp hai. Aur versioned keys, jaise user colon bayalees colon version sattrah, invalidation ko bilkul side-step kar dete hain. Ek nayi version ek nayi key hoti hai. Dhyaan rakho, cache add karna paanch minute ka kaam hai, par yeh guarantee karna ki wo galat answer kabhi galat waqt par na de, wahi asli mehnat hai.
Kaam ruk sakta hai to queue mein daalo Slide 5
Teesra pattern, jab kaam ruk sakta hai to use queue mein daal do. Ek synchronous call aapko apni sabse slow dependency se baandh deti hai. Uski latency aapki latency ban jaati hai, aur uska failure aapka failure. Ek queue is chain ko independent stages mein tod deti hai, jo apne apne timeline par scale, retry, aur fail karti hain. Producer likhkar aage badh jaata hai, aur workers ka pool queue ko apni speed se drain karta hai. Ek traffic spike sirf queue ko gehra kar deta hai, kisi service ko gira nahi deta. Idempotent consumers aur ek dead-letter queue ke saath retries safe ho jaate hain. Cost sirf itni hai, ab dashboard mein queue depth, sabse purane message ki age, aur consumer lag dekhne padte hain.
Replicate for availability, shard for capacity Slide 6
Chautha pattern, availability ke liye replicate karo aur capacity ke liye shard karo. Yeh alag alag levers hain, aur zyadatar dard inhe confuse karne se aata hai. Replication same dataset ko kai nodes par copy karti hai. Isse aap node loss survive karte ho aur reads scale karte ho, par capacity nahi badhti, kyunki har replica sab kuch rakhta hai. Sharding dataset ko ek key se nodes mein baant deti hai. Isse write throughput aur storage ek machine se aage badhte hain, par cross-shard joins aur painful rebalancing milte hain. Bade systems jo combination pakadte hain wo yeh hai, pehle capacity ke liye shard karo, phir har shard ko availability ke liye replicate karo. Aur shard key wo decision hai jise baad mein badalna aasan nahi, to soch samajhkar chuno.
Reads ke liye denormalize karo Slide 7
Paanchwa pattern, reads ke liye denormalize karo, aur maan lo ki writers baad mein catch up karenge. Ek normalized schema elegant hai par slow, kyunki har read joins se answer banata hai. Jab reads writes se bahut zyada ho jayein, jaise feed, search, ya profile page, tab data ko aise shapes mein copy karo jo har query se match karein, taaki read ek single lookup ban jaye. Fan-out on write ka matlab, jab koi post kare to item ko har follower ke inbox mein push kar do. Write mehnga, read trivial. Par yeh celebrity ke liye toot jaata hai jiske lakhon followers hain, unke liye fan-out on read par flip karo. Aur ek rebuild path hamesha rakho, kyunki copies drift karti hain, jab nahi, to. Eventual consistency accept karna sloppiness nahi, ek product decision hai. Ek like count kuch second lag kare to koi baat nahi, par bank balance lag kare to sab kuch bigad jaata hai.
CAP — network toote to ek side chuno Slide 8
Ab tradeoff, CAP practice mein. Partitions rare, brief, aur bahut kam total hote hain, isliye textbook theorem asli zindagi se zyada stark hai. Useful framing per-operation hai. Jab network split ho, to har call ko ya to pause karna hoga jab tak wo consistent na ho jaye, ise CP kehte hain, ya phir possibly stale data ke saath answer dena hoga aur baad mein reconcile karna hoga, ise AP kehte hain. Banking, ticket inventory, aur distributed locks CP ki taraf jhukte hain, kyunki das second unavailable rehna behtar hai double-spend se. Social feed, catalogue, aur DNS AP ki taraf jhukte hain, kyunki thoda stale last-seen theek hai par error page nahi. Aur jab aap data centres span karte ho, to P optional nahi rehta, aap asal mein C ya A chunte ho.
Latency, throughput, cost, reliability Slide 9
Doosra tradeoff. Koi system ek saath chaaron mein achha nahi hota. Ek, latency versus throughput. Batching aur buffering aggregate throughput badhate hain par har single request ka wait bhi badha dete hain. Do, cost versus reliability. Har extra nine lagbhag das guna mehnga hota hai, to decide karo ki kaunsa journey sach mein five nines maangta hai. Teen, consistency versus availability, jo CAP hi hai. Aur chaar, simplicity versus scale, kyunki har cache, shard, aur queue ek aur cheez hai jise aadhi raat ko debug karna padega. Jab confuse ho, to instinct se machinery mat jodo. Sabse sasti ladder chadho jise numbers justify karein, aur har rung ke baad dobara measure karo.
Isme behtar kaise banein Slide 10
Ab practice. Chapters padhna aasan hissa hai, skill habit se compound hoti hai. Teen practices. Ek, sabse chhoti version banao. Ek multi-node cache khada karo aur ek node ko write ke beech maar do. Ek queue do services ke beech lagao aur consumer ko jaan boojhkar slow karke lag dekho. Cheez chalao aur todo, yeh diagram se zyada sikhata hai. Do, doosron ka source padho. Koi ek open-source system jis par aap depend karte ho, jaise Postgres, Kafka, ya etcd, uske design docs end to end padho, aur ek request ko code mein trace karo. Teen, har hafte kaagaz par design karo. Koi product chuno aur wo hissa likho jise aap sabse kam samajhte ho, adjectives nahi, numbers ke saath. Ek mahine baad dobara padho aur dekho kya galat tha.
Paanch principles Slide 11
To paanch principles yaad rakho jo saara chapter samet lete hain. Ek, interesting sawaal hamesha yeh hai ki aage kya fail karega. Har component ka ek breaking point hai, jaano kaunsa pehle jayega. Do, wo sabse simple cheez chuno jo aapke agle das guna growth ko survive kare, agle hazaar guna ko nahi. Teen, state horizontal scale ki dushman hai, use edges par push karo aur beech ki layer disposable rakho. Chaar, eventual consistency theek hai agar aap naam de sako ki wo kab maayne rakhti hai. Aur paanch, har choice ka ek bill hota hai, use jaan boojhkar bharo. Latency, cost, complexity, ya operational burden, goal bill se bachna nahi, balki jaanna hai ki aap kaunsa sign kar rahe ho.
Aage kya
Bas, yahi hai chapter solah, aur yahi is series ka ant. Ek kaam karo, koi bhi product chuno jise aap roz use karte ho, aur teen toolkit components naam do jo usme hone hi chahiye, aur har ek ke liye bolo ki agar hata dein to kya toot jayega. Phir ek read path aur ek write path chuno aur har ek ko CP ya AP label karo. Koi bhi pattern ya tradeoff confuse kare to mujhse pooch lena. Aur jab man kare, to pehle chapter par wapas jaakar scaling ki ladder dobara dekh lena, kyunki yeh sab wahin se shuru hua tha.