← कोर्सच्या मुख्य पानाकडे परत

📐 18 धडे आकृत्यांमध्ये

भाग 1: पद्धत (indigo, 1–4) · भाग 2: बांधणीचे ठोकळे (amber, 5–12) · भाग 3: प्रत्येक box मध्ये लागू होणारे (red, 13–16) · भाग 4: सोडवलेल्या रचना (green, 17–18). प्रत्येक आकृती खऱ्या lab वरून काढलेली आहे — design/demo.py जे आकडे print करते तेच — आणि प्रत्येकीखाली एक lab आहे जिथे तुम्ही ते बदलू शकता. वर्तुळातले क्रमांक 1 → 2 → 3 या क्रमाने पाहा.

1 📋 गरजा आणि मर्यादा

नियोजन कार्यालय काढण्याआधी विचारते — functional, non-functional, मर्यादा (constraints), आणि काय कक्षेबाहेर आहे.

🧒 सोप्या शब्दांत

शाळा सांगते: 5 million पालकांसाठी सूचना फलक app बनवा. Dipika अजून काहीच काढत नाही. आधी ती विचारते: काय करायचे, किती जलद हवे, आणि मर्यादा काय. आपण काय बनवणार नाही, जसे chat, तेही ती लिहिते. आता सगळे एकच गोष्ट आखतात.

📖 नवे शब्दfunctional — app ने काय करायचे: शिक्षिका post करते, पालक वाचतात, तातडीच्या सूचनांची notificationnon-functional — ते किती चांगले चालायला हवे: read p99 < 200 ms, 99.9% availableconstraints — ठरलेल्या मर्यादा: 4 जणांची team, AWS, मराठी + English, 3 महिन्यांत launchout of scope — आत्ता काय बनवणार नाही, मोठ्याने सांगितलेले: chat, payments, video
1📋 काम (brief) दीपिकाच्या नियोजन टेबलावर येते — कोणताही box काढण्याआधी ती पत्रक लिहिते📨 काम (BRIEF)“50 लाख पालकांसाठीसूचना फलक app बांधा”Katrinaकाम घेऊन येतेदीपिका — नियोजकते काय करायला हवे?किती चांगले — जलद, चालू, सुरक्षित?कोणत्या मर्यादांमध्ये?ते काय करणार नाही?आधी पत्रक, आकृती नव्हे — नंतरचा प्रत्येकbox त्यातल्या एखाद्या ओळीकडे बोट दाखवायला हवाFUNCTIONAL — ते काय करतेशिक्षक वर्गासाठी सूचना टाकतातपालक आपल्या मुलांच्या वर्गांच्या सूचना वाचताततातडीच्या सूचनांसाठी पालकांना notification मिळतेNON-FUNCTIONAL — किती चांगले⏱ read p99 < 200 ms · post p99 < 500 ms⬆ 99.9% उपलब्ध⚖ reads ची संख्या posts पेक्षा ~100 : 1 जास्त🔒 एकदा 'posted' दाखवल्यावर सूचना कधीही हरवता कामा नयेCONSTRAINTS — मर्यादा4 जणांची टीम · AWS · मराठी + Englishबजेट: महिन्याला काही हजार dollars3 महिन्यांत launchकक्षेबाहेर — ते सांगा!chatपेमेंट्सvideoआत्ता नाही2❓ काहीही काढण्याआधी तीन प्रश्नDipikaकिती शाळा?प्रत्येक आकडा ठरवतेधडा 02peak कधी असतो?×3 साठी नियोजन करा,सरासरीसाठी नव्हेdata किती काळ ठेवायचा?5 वर्षे × 3 प्रती= storage चे बिलप्रत्येक उत्तर एक आकडा बदलते — आणि आकडे आकार बदलतात3🎯 "किती चांगले" हे तपासता येणारी उद्दिष्टे बनतेread p99 < 200 ms100 पैकी 99 feed reads त्यापेक्षा जलदpost p99 < 500 msposting थोडे सावकाश चालेल99.9% उपलब्ध = 30 दिवसांत जास्तीत जास्त 43.2 मिनिटे बंद↑ 43.2 min म्हणजे एका दिवसाचा 3% — ती लाल पातळ पट्टी1 पोस्ट100 वाचनेपोस्टपेक्षा वाचने कितीतरी जास्त~100 : 1 → म्हणून रचनावाचनाकडे झुकते'posted' झालेली सूचना कधीही हरवू नका → lesson 08
⏪ आधी

Teams नी 'सूचना फलक app बनवा' ऐकले आणि लगेच boxes काढले, मग खऱ्या गरजा launch नंतर कळल्या.

💡 काय

गरजा म्हणजे नियोजन कार्यालय आधी विचारते: काय करायचे, किती चांगले, कोणत्या मर्यादेत, आणि काय बाहेर ठेवायचे.

⚙️ कसे

5M पालकांसाठी: read p99 < 200 ms, post p99 < 500 ms, 99.9% up, reads 100:1, 4 जणांची team; chat आणि payments बाहेर.

🎯 का

लिहिलेला कागद कार्यालयाला चुकीची गोष्ट बांधण्यापासून थांबवतो, आणि out-of-scope ओळ योजना फुगू देत नाही.

🚀 पुढे

पुढचा धडा कागदाला आकड्यांत बदलतो: पालकांचे requests per second, peak, storage आणि servers होतात.

🧪 इथे करून पाहा — brief मधील प्रत्येक वाक्य sheet मध्ये लावा — functional, non-functional, constraint की out of scope?

पूर्ण धडा 01 वाचा →

2 🧮 क्षमतेचा अंदाज

रचनेचा आकार ठरवणारे कच्चे (back-of-the-envelope) आकडे — users → requests/s → peak → storage → servers.

🧒 सोप्या शब्दांत

शाळेच्या कार्यक्रमासाठी खुर्च्या आणण्याआधी पाहुणे मोजतात. Dipika app साठी तेच गणित करते. दिवसाला 1 million सूचना म्हणजे सेकंदाला सुमारे 12. Reads 100 पट जास्त, आणि गर्दीचा तास नेहमीच्या 3 पट. म्हणून ती सेकंदाला 3,507 requests आणि 12 servers साठी योजना करते.

📖 नवे शब्दestimate — कागदावरचा ढोबळ अंदाज, आकार निवडायला पुरेसाpeak — सर्वात गर्दीचा क्षण; इथे सरासरीच्या 3 पट, 3,507 req/sstorage — किती data साठतो: 2 KB × दिवसाला 1M × 5 वर्षे × 3 प्रती = 10.95 TB10^5 — एक दिवस 86,400 s, म्हणजे सुमारे 10^5 सेकंद: दिवसाला 1M ≈ सेकंदाला 12
1🧮 envelope वरचे गणित — Dipika ची वही 5 million पालकांचे requests per second मध्ये रूपांतर करते5,000,000 पालक × 0.2 = 1,000,000 सूचना / दिवस11,000,000 ÷ 86,400 s = 11.6 writes/s2× प्रत्येकी 100 reads = 1,157.4 reads/s3(1M + 100M) ÷ 86,400 = सरासरी 1,169 req/s41,169 × 3 (peak) = 3,507 req/s5ceil(3,507 ÷ (500 × 60%)) = 12 servers61M × 2 KB × 365 × 5 y × 3 = 10.95 TB73,507 × 2 KB = 7.0 MB/s बाहेर8एक दिवस ≈ 86,400 s ≈ 10⁵ · 1M/दिवस ≈ 12/s · 2 KB × 1M = 2.0 GBउत्तर म्हणजे एक आकार (SHAPE) आहे, एखादा आकडा नाही:छोटे writes, भरपूर reads → reads cache करा✏️ गोल आकडे,पद्धत महत्त्वाची5,000,000 पालक÷ 86,400 सेकंदम्हणजे एक दिवससरासरी 1,169 req/speak ला 3,507 req/s (×3)500 req/s चे 12 servers, 60% वर चालवलेले(अचानक वाढ किंवा बंद पडलेल्या server साठी जागा)2📅 एका दिवसाचे traffic — सरासरीसाठी नव्हे, peak साठी नियोजन करा01,0002,0003,0004,000सरासरी 1,169 req/speak ×3 = 3,507 req/s — याच्यासाठी आकार ठरवा0 hसकाळी 8दुपारी 2रात्री 824 hपालक जेवणानंतर वाचतात →उदाहरणादाखल दिवस — ×3 peak factor हा नियम आहे; वक्ररेषा फक्त एक रेखाटन आहे3💾 storage दरवर्षी वाढते — प्रत्येक सूचनेच्या 3 प्रती2.19वर्ष 14.38वर्ष 26.57वर्ष 38.76वर्ष 410.95वर्ष 510.95 TB5 वर्षांनंतरप्रत्येक पट्टी = 3 प्रती(3 छटा)दिवसाला 2 KB × 1M= दिवसाला 2.0 GB× 365 × 3 प्रती= वर्षाला 2.19 TB7.0 MB/s बाहेरpeak ला (≈ 56 Mb/s)एक database cluster पुरेसा आहे
⏪ आधी

योजनांत 'खूप पालक' एवढेच लिहिलेले असे आणि machines अंदाजाने ठरत, म्हणून काही लहान पडत आणि काही खूप महाग.

💡 काय

Capacity अंदाज म्हणजे कार्यालयाचे कागदावरचे ढोबळ गणित: पालक ते requests, peak, storage आणि servers.

⚙️ कसे

दिवसाला 1M सूचना म्हणजे 11.6 writes/s आणि 1,157 reads/s; peak ×3 ला 3,507 req/s, 12 servers; 5 वर्षांत 10.95 TB.

🎯 का

आकडे आकार दाखवतात: writes लहान, reads जड, म्हणून reads cache करा आणि एक database cluster पुरेसा आहे.

🚀 पुढे

पुढचा धडा आधी करार लिहितो: resources, status codes, idempotency keys आणि cursor pagination.

🧪 इथे करून पाहा — envelope calculator — blocks.py मधील estimate(); slider हलवा आणि आकार बदलताना पाहा
50.21002350053

पूर्ण धडा 02 वाचा →

3 🔌 API ची रचना

आधी करार (contract) — resources, status codes, idempotency keys, cursor pagination आणि versioning.

🧒 सोप्या शब्दांत

Canteen उघडण्याआधी कार्यालय सगळ्यांसाठी एकच मागणी-फॉर्म छापते. App आणि server आधी त्याच फॉर्मवर सहमत होतात. शिक्षिकेने post दोनदा दाबले तरी फॉर्मवरची key दुहेरी सूचना थांबवते. मोठ्या यादीसाठी पुन्हा page 1 पासून मोजण्याऐवजी bookmark ठेवायचा.

📖 नवे शब्दresource — पत्ता असलेली गोष्ट, जसे /classes/3A/noticesstatus code — छोटा उत्तर-क्रमांक: 201 created, 403 तुमचा वर्ग नाही, 429 हळूIdempotency-Key — request वरचे तिकीट, म्हणजे retry मुळे सूचना कधी दोनदा लागत नाहीcursor — bookmark: page 5,000 ला 20 rows, OFFSET सारख्या 100,000 नाहीत
1🔌 आधी करार (contract) — तीन खिडक्या, कृतींवरून नव्हे तर RESOURCES (नामे) वरून नाव दिलेल्याPOST /classes/3A/noticesKatrina post करतेविनंतीIdempotency-Key: K1{title, text, urgent}201 CreatedLocation:/classes/3A/notices/91GET /classes/3A/noticesAishwarya 3A वाचतेविनंती?limit=20&cursor=eyJpZCI6OTB9200 OK{items: [20 notices], next_cursor: "eyJp…"}GET /parents/me/feedAishwarya, सर्व वर्गविनंती?limit=20Authorization: Bearer …200 OKमाझ्या सर्वमुलांच्या वर्गांच्या सूचनाpath मध्ये नामे, क्रियापद म्हणजे HTTP method: POST तयार करते, GET वाचते — /createNotice नाही, /getFeed नाहीcursor म्हणजे फक्त {"id":90} चे base64 — "सूचना 90 नंतर सुरू करा"; server पुढचा cursor परत देतोकोणताही server code लिहिण्यापूर्वी contract (OpenAPI) लिहिला जातो — app team आणि server team एकाच वेळी त्याच्या आधारे बांधणी करतात2🔑 दोनदा post होता कामा नये असा retryKatrinaPOST · key K1जतन झालीसूचना 91✂ उत्तर हरवलेretry · key K1📒 key ची नोंदवहीK0 → 201 /88K1 → 201 /91K1 आधी पाहिलेली →तेच उत्तर पुन्हा:201, काहीही जतन नाहीकितीही retries झाले तरी सूचना 91 एकच — K1 वेगळ्या body सह परत आली तर 409GET, PUT आणि DELETE स्वभावतःच idempotent आहेत; POST ला key लागते3🚦 उत्तराची चिठ्ठी — status codes आणि versions200OK201तयार झाले400चुकीचे input401तुम्ही कोण?403तुमचा वर्ग नाही404अशी सूचना नाही409दुहेरी429हळू घ्या2xx काम झाले · 4xx caller ने काहीतरी बदलायला हवे · 5xx आमची चूक, retry करा/v1अजूनही दिले जाते/v2नवा आकारनवीन fields जोडा,प्रकाशित झालेलाकधीही मोडू नका किंवात्याचे नाव बदलू नका4📖 एका वर्गाच्या feed चे पान 5,000 — प्रत्येक पान उलटायचे (OFFSET) की bookmark वर उघडायचे (cursor)?OFFSET 99,980 LIMIT 20100,000 rows वाचतो, 20 ठेवतोWHERE id < 90 … LIMIT 20index मध्ये थेट जातो, 20 वाचतोdatabase ज्या rows मधून जातो (प्रति पान 20, log scale)पान 1OFFSET 20cursor 20पान 50OFFSET 1,000cursor 20पान 5,000OFFSET 100,000cursor 20
⏪ आधी

Screens आणि servers वेगवेगळे बनले आणि उशिरा जुळवले, आणि page 5,000 ला database ला प्रत्येक row चालावी लागली.

💡 काय

API design म्हणजे कार्यालयाचा मागणी-फॉर्म, बांधण्याआधी ठरलेला: resources, स्पष्ट errors आणि सुरक्षित retries.

⚙️ कसे

Idempotency-Key सह POST /classes/3A/notices ला 201 मिळतो; page 5,000 वर OFFSET 100,000 rows चालतो, cursor फक्त 20.

🎯 का

Teams दोन्ही बाजू एकाच वेळी बांधतात, retry मुळे सूचना दोनदा लागत नाही, आणि खोल pages पण page 1 इतकेच जलद.

🚀 पुढे

पुढचा धडा आपण विचारणार त्या प्रश्नांवरून data मांडतो, आणि मग store निवडतो.

🧪 इथे करून पाहा — OFFSET ने किंवा cursor ने पान N पर्यंत जा — मग Idempotency-Key सह आणि त्याशिवाय POST चा retry करा
500020

पूर्ण धडा 03 वाचा →

4 🗄️ Data model आणि database ची निवड

तुम्ही जे प्रश्न विचाराल त्यांचे model करा, मग store निवडा — मूलतः relational, इतर खऱ्या कारणांसाठीच.

🧒 सोप्या शब्दांत

ग्रंथालय वाचक विचारतात त्या प्रश्नांनुसार पुस्तके लावते, जसे विषयानुसार. Dipika आधी प्रश्नांची यादी करते: वर्ग 3A च्या नव्या सूचना दाखवा. मग ती नेमक्या त्यासाठी एक table आणि एक index बनवते. साधा relational database हा तिचा सुरक्षित default. नवा प्रश्न आला तरच ती दुसरे stores जोडते.

📖 नवे शब्दaccess pattern — app data ला पुन्हा पुन्हा विचारतो तो प्रश्नrelational — joins आणि transactions असलेली tables; सुरक्षित default (PostgreSQL)key-value — एक key, एक value: ठरलेल्या lookups साठी प्रचंड scale वर खूप जलदindex — rows पटकन शोधणारी क्रमवार यादी: (class_id, created_at DESC)
1🗄️ प्रश्नापासून सुरुवात करा — "3A वर्गात नवीन काय आहे?" — मग table आणि त्याचा index घडवाAishwarya3A मध्ये नवीन काय?SELECT * FROM noticesWHERE class_id = '3A'ORDER BY created_at DESCLIMIT 20access pattern, लिहून काढलेलाnotices — एक tableidclass_idलेखकशीर्षकurgentcreated_at882BMeeraक्रीडा दिननाही09-24 10:02893AKatrinaसोमवारी परीक्षाहो09-24 11:40901CZoyaजेवणाचा मेनूनाही09-25 08:15913AKatrinaसहलीचा फॉर्मनाही09-26 16:30922BMeeraसुट्टीनाही09-27 09:05+ text · rows वेळेच्या क्रमाने येतात, वर्ग मिसळलेले असतातindex (class_id, created_at DESC)1C · 09-252B · 09-272B · 09-243A · 09-26 → 913A · 09-24 → 894D · 09-203A च्या cards वर थेट जा, क्रमाने 20 वाचाएकच seek — सूचना कितीही असोतएक table, एक index, एक प्रश्न जलद सुटलेला — नवीन access pattern ला गरज असेल तेव्हाच stores वाढवा2🧭 stores चे कपाट — प्रश्न store निवडतात; जुळणारा पहिला नियम जिंकतो (choose_store)transactions + joins?नाही ↓होrelationalPostgreSQL / Auroraगुण, फी, bookings — ज्यांचा हिशेब जुळलाच पाहिजे अशा गोष्टीkey-lookup + huge-scale?नाही ↓होkey-value / wide-columnDynamoDB / Cassandrasessions, carts, प्रत्येक पालकासाठी एक feed — key ने मिळवाsearch?नाही ↓होsearch engineOpenSearch"trip चा उल्लेख असलेल्या सूचना शोधा" — ids नव्हे, शब्दsimilarity?नाही ↓होvector indexpgvector / OpenSearch k-NN"या सूचनेसारख्या सूचना" — नकाशावरील सर्वात जवळचे बिंदूfiles?नाही ↓होobject storageS3फोटो, PDFs, प्रगतिपुस्तके — मोठे blobs, स्वस्तtime-series?नाही ↓होtime-series storeTimestream / Prometheusदर मिनिटाचे metrics — append करा, मग ranges वाचायापैकी काहीच नाहीelserelational — सुरक्षित defaultPostgreSQLएखादा access pattern वेगळे सांगेपर्यंतसूचना फलक → relational
⏪ आधी

प्रत्येक नवे app आधी फॅशनचा database निवडे, मग स्वतःच्या प्रश्नांची उत्तरे मिळवण्यासाठी वर्षानुवर्षे झगडे.

💡 काय

Data model म्हणजे कार्यालयाचे कपाट, त्याला विचारल्या जाणाऱ्या प्रश्नांवरून आखलेले; relational हा default.

⚙️ कसे

notices(id, class_id, …) हे एक table आणि (class_id, created_at DESC) index '3A च्या नव्या सूचना' पटकन देतात.

🎯 का

एक table, एक index, एक जलद उत्तर; S3, search किंवा vectors फक्त खरा access pattern मागेल तेव्हाच जोडायचे.

🚀 पुढे

पुढचा धडा भाग 2 पहिल्या बांधणीच्या ठोकळ्याने उघडतो: caching, प्रती कुठे आणि किती ठेवायच्या.

🧪 इथे करून पाहा — data ला काय लागते ते tick करा — choose_store() आपले नियम तपासते आणि पहिला जुळणारा नियम जिंकतो

पूर्ण धडा 04 वाचा →

5 📌 Caching

प्रती कुठे ठेवायच्या, किती मोठ्या, किती काळ — hit-ratio वक्र आणि काय invalidate करायचे.

🧒 सोप्या शब्दांत

कार्यालय सर्वात जास्त मागितल्या जाणाऱ्या सूचनांच्या झेरॉक्स प्रती समोरच्या टेबलावर ठेवते. बहुतेक पालकांना त्याच थोड्या सूचना हव्या असतात, म्हणून कपाट कमी वेळा उघडावे लागते. Dipika ट्रेचा आकार तपासते. 10% वर्ग ठेवले तरी 64% reads ची उत्तरे मिळतात. सूचना बदलली की जुनी प्रत फेकून दिली जाते.

📖 नवे शब्दcache — लोकप्रिय data ची जवळची प्रत, म्हणजे database ला कमी विचारावे लागतेhit ratio — प्रत किती वेळा मिळाली: आकार वाढतो तसे 33.8%, 64.0%, 83.1%LRU — least recently used: भरल्यावर, सर्वात जास्त काळ न मागितलेले काढून टाकाinvalidate — खरी सूचना बदलली की प्रत फेकून द्या, किंवा छोटा TTL वापरा
1📌 hit-ratio वक्र — 5,000 वर्गांवरील 20,000 feed reads एका LRU cache मधूनप्रत्येक वर्ग किती वेळा मागितला जातो (5,000 पैकी सर्वात लोकप्रिय 40)वर्ग #1: 2,204 reads#10: 205Zipf: वर्ग #k हा #1 च्या ~1/k इतक्या वेळा मागितला जातो5,000 पैकी 3,223 वर्ग एकदाच वाचले जातात किंवा कधीच नाही —लोकप्रिय थोड्यांचा cache बहुतेक reads पकडतो0%25%50%75%100%510501005001,0005,000cache ठेवू शकणारे वर्ग (log scale)hit ratioकमाल 83.9%: पहिले read नेहमी miss होते50 → 33.8%1% वर्ग500 → 64.0%10%2,500 → 83.1%50%छोटा cache लोकप्रिय अर्धा भाग पकडतो — आकार ठरवणे हा एक वक्र आहे, तो मोजा2🧅 प्रती कुठे राहतात — सर्वात जवळची आधी📱 browser / appCache-Control: max-age🌍 CDN edgeसगळ्यांसाठी तेच पान🧰 API + Redisfeed:3A → 20 सूचना🗄️ database buffermemory मधील hot pages💽 diskसत्याचा स्रोतAishwaryaजलदहळू, पण खरे3♻️ cache-aside, आणि write वेळी विसरून जावाचनAPIRedisfeed:3A · TTL 60 sसूचना① gethit → झाले② miss → API DB वाचते③ …आणि key set करतेWRITEKatrinaINSERT notice 92 (class 3A)सूचनाfeed:3ADEL keyपुढचे read एकदा miss होते आणि notice 92 सह पुन्हा भरतेकिंवा सोपे ठेवा: छोटा TTL — काही वाचकांना सूचना60 s पर्यंत उशिरा दिसू शकते; हे sheet वर स्पष्ट लिहा
⏪ आधी

प्रत्येक feed read database कडे जाई, सेकंदाला 1,157 reads, आणि database च bottleneck बनला.

💡 काय

Cache म्हणजे कार्यालयाचा झेरॉक्स ट्रे: लोकप्रिय सूचनांच्या प्रती जवळ, म्हणजे कपाट कमी वेळा उघडावे लागते.

⚙️ कसे

5,000 वर्गांवर 20,000 reads: 1% ठेवणारा LRU 33.8% hit, 10% ठेवणारा 64.0%, 50% ठेवणारा 83.1% hit.

🎯 का

फक्त 1% classes ठेवणारा cache एक तृतीयांश reads पकडतो, latency आणि database चा खर्च एकत्र कमी होतो.

🚀 पुढे

पुढचा धडा visitors आणि keys पसरवतो: load balancers आणि फक्त एक वाटा हलवणारी hash ring.

🧪 इथे करून पाहा — 5,000 वर्गांवरचे 20,000 feed reads (zipf_stream) एका LRUCache मधून — त्याचा आकार ठरवा
500

पूर्ण धडा 05 वाचा →

6 ⚖️ Load balancing + consistent hashing

पाहुणे आणि keys पसरवा — L4 vs L7, health checks, आणि असा ring जिथे server जोडल्यावर फक्त त्याचा वाटा हलतो.

🧒 सोप्या शब्दांत

Gate वरचा द्वारपाल प्रत्येक पालकाला उघड्या खिडकीकडे पाठवतो. सूचना वर्गानुसार 4 कपाटांत वाटलेल्या आहेत. नियम 'वर्ग क्रमांक mod 4' असेल, तर 5 वे कपाट आले की जवळजवळ प्रत्येक file हलते. Ring वर, नवे कपाट फक्त स्वतःचा वाटा घेते, 5 पैकी 1.

📖 नवे शब्दload balancer — requests निरोगी servers वर पसरवणारा द्वारपालhealth check — नियमित 'बरे आहात का?', म्हणजे traffic आजारी server टाळतेconsistent hashing — servers ची ring; नवा server सुमारे 1/N keys हलवतो (20%, 80% नाही)L4 vs L7 — L4 फक्त TCP पाहतो आणि जलद; L7 HTTP paths आणि headers वाचतो
1⚖️ दारावरचा मार्गदर्शक — load balancer पालकांना विभागून पाठवतो आणि आजारी खिडकी टाळतोपालकload balancersrv-13 उघडी connectionssrv-21 उघडे connectionsrv-3✗ health check अयशस्वीsrv-42 उघडी connectionsround robin: 1 → 2 → 4 → 1 → 2 → 4 …least connections: पुढचा srv-2 कडे (1 उघडे)health check: दर 10 s ला GET /health, 3 अपयश = बाहेरstateless servers — कोणताही server कोणालाही उत्तर देऊ शकतोL4 — बंद लिफाफा10.0.3.7 : 443फक्त IP + port (TCP) पाहतोखूप जलद, कोणताही protocolpath नुसार route करू शकत नाहीL7 — उघडलेले पत्रGET /api/notices …Host: notices.schoolCookie: lang=mrHTTP वाचतो: path, host, headers/api/* → API pool/photos/* → photo pool · TLS इथे संपतेबहुतेक web apps: पुढे एक L7 (उदा. AWS ALB)2🎲 hash % N — 5 वा cache server सामील होतो10,000 class keys पैकी पहिल्या 100: आधीचा server | नंतरचा→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→यापैकी 100 मधील 78 हलल्या (काळी चौकट) — मालक key·k % 4, मग % 510,000 पैकी 8,001 keys हलतात (80%)जवळपास प्रत्येक key चा server बदलतो: caches थंड पडतातएकाच वेळी आणि संपूर्ण वादळ database वर येते— सुमारे 1 − 1/5 keys, hash कोणताही असोs0s1s2s3s43💍 consistent hashing — फक्त नव्या server चा वाटा हलतो5 servers × 100virtual nodes100 पैकी 17 keys हलल्याkey जातेघड्याळाच्या दिशेने पुढच्या बिंदूकडेs4 (जाड गुलाबी) ने घेतलेछोटे तुकडेप्रत्येक server कडून — फक्तत्या तुकड्यांमधील keysहलल्या, सगळ्या s4 कडे1,975= 20% हलतात · सुमारे 1/5, नवा वाटानंतर प्रत्येक server वरील keys (10,000 keys):1,883s02,016s11,989s22,137s31,975s4
⏪ आधी

Keys hash % N ने ठेवल्या जात, म्हणून एक cache server जोडला की जवळजवळ सगळे हलत आणि caches रिकामे होत.

💡 काय

Load balancing म्हणजे कार्यालयाचा द्वारपाल पालकांना उघड्या खिडक्यांकडे पाठवतो; hash ring प्रत्येक key ला ठरलेले घर देते.

⚙️ कसे

4 servers वर 10,000 वर्ग, 5 वा जोडला: hash % N 8,001 keys (80%) हलवतो, ring फक्त 1,975 (20%).

🎯 का

नवा server फक्त स्वतःचा वाटा घेतो, म्हणून caches गरम राहतात आणि servers वाढवणे शांतपणे होते.

🚀 पुढे

पुढचा धडा पटकन उत्तर देतो आणि हळू काम नंतर करतो: queues, workers, retries आणि DLQ.

🧪 इथे करून पाहा — hash ring वर 10,000 class keys (खरा md5) — server जोडा किंवा काढा आणि कोण हलते ते मोजा
100

पूर्ण धडा 06 वाचा →

7 📬 रांगा (queues) आणि async काम

पटकन उत्तर द्या, सावकाश काम नंतर करा — jobs, workers, retries, DLQs आणि at-least-once delivery.

🧒 सोप्या शब्दांत

कार्यालयात तुम्ही फॉर्म ट्रेमध्ये टाकता आणि लगेच शिक्का मिळतो. कारकून सगळे काम करेपर्यंत तुम्ही थांबत नाही. App 5 million SMS चे तेच करते. ते शिक्षिकेला 50 ms मध्ये उत्तर देते आणि queue वर एक job ठेवते. 50 workers असले तर सगळे SMS 33 मिनिटांत जातात.

📖 नवे शब्दqueue — नंतर क्रमाने करायच्या jobs ची रांगworker — queue वरून jobs घेणारा मदतनीस; जास्त workers म्हणजे लवकर काम पूर्णDLQ — dead-letter queue: सगळ्या retries नंतरही अपयशी jobs साठी कप्पाat-least-once — एक job दोनदा चालू शकतो, म्हणून दोनदा करणे सुरक्षित हवे
1📬 "5M तातडीचे SMS पाठवा" request च्या आत चालता कामा नये — लवकर उत्तर द्या, हळू काम नंतर कराKatrinaतातडीची सूचनाPOSTAPI① सूचना save करा② रांगेत (queue) एकच job टाका③ 201 उत्तर द्या~50 ms~50 ms मध्ये 201 ✓रांग (SQS): 500 SMS चे 10,000 jobsworker delete करेपर्यंत jobs इथे सुरक्षित थांबतातworkers×500पालकांचे फोनप्रत्येक worker:एक job घ्या,500 पाठवा,job delete कराकाम झाल्यावरपाठवणे अयशस्वी झाल्यास1 s नंतर पुन्हा प्रयत्न2 s नंतर पुन्हा प्रयत्न4 s नंतर पुन्हा प्रयत्नDLQ — माणसासाठी बाजूला ठेवलेलेbackoff दुप्पट होतो:SMS gateway लासावरायला वेळ मिळतोat-least-once delivery:पाठवल्यानंतर worker crash होऊ शकतो,म्हणून job पुन्हा चालतो → पाठवतानाप्रत्येक (सूचना, पालक) साठी एक key: दुहेरी SMS नाहीरांगा वेग वेगळा करतात: request जलद, काम तुम्ही जितके पैसे मोजाल तितके जलद2⏱️ 5M किती लवकर जातात = तुम्ही किती workers साठी पैसे मोजता (प्रत्येक सेकंदाला 50 SMS पाठवतो)10 workers166.7 min5,000,000 ÷ (10 × 50) ÷ 60 = 166.7 मिनिटे50 workers33.3 min5,000,000 ÷ (50 × 50) ÷ 60 = 33.3 मिनिटे200 workers8.3 min5,000,000 ÷ (200 × 50) ÷ 60 = 8.3 मिनिटेrequest तरीही ~50 ms मध्येच उत्तर देते — workers हे वेग आणि खर्च यांमधील dial आहेत
⏪ आधी

Post request स्वतःच 5M तातडीचे SMS पाठवायचा प्रयत्न करी, म्हणून शिक्षिका थांबून राही आणि request timeout होई.

💡 काय

Queue म्हणजे कार्यालयाचा in-tray: कारकून लगेच मागणीवर शिक्का मारतो, आणि workers हळू काम नंतर करतात.

⚙️ कसे

Request ~50 ms मध्ये 201 देतो; 50 SMS/s वेगाने 10 workers ला 166.7 min, 50 workers ला 33.3 min, 200 ला 8.3 min.

🎯 का

Request जलद राहतो, काम तुम्ही पैसे द्याल तितक्या वेगाने होते, आणि अपयश retry होते किंवा DLQ मध्ये थांबते.

🚀 पुढे

पुढचा धडा एका घटनेला अनेक ऐकणारे देतो: pub/sub events, fan-out आणि outbox.

🧪 इथे करून पाहा — "5M तातडीचे SMS पाठवा" — request एक job रांगेत टाकते; तो किती workers रिकामा करतील ते तुम्ही ठरवा
10505

पूर्ण धडा 07 वाचा →

8 📣 Events (घटना), pub/sub आणि outbox

एक तथ्य, अनेक ऐकणारे — pub/sub, fan-out on write vs read, आणि DB व broker यांच्यामध्ये कधीही event (घटना) न गमावणे.

🧒 सोप्या शब्दांत

सूचना post झाली की अनेक जण प्रतिसाद देतात: email, SMS, search. कार्यालय एकदाच घोषणा करते आणि ज्यांना हवे ते ऐकतात. पण कारकुनाने सूचना save केली आणि मग तो बेशुद्ध पडला, तर घोषणा हरवते. म्हणून चिठ्ठी सूचनेसोबत outbox मध्ये जाते. Crash नंतरही एक मदतनीस ती नंतर पाठवतो.

📖 नवे शब्दevent — भूतकाळातील घटना, जसे NoticePostedpub/sub — एकदा publish करा, प्रत्येक subscriber ला स्वतःची प्रत मिळतेoutbox — data सोबत एकाच transaction मध्ये save केलेला event, नंतर relay पाठवतोfan-out — push प्रत्येक inbox लिहितो (200 writes); pull वाचताना गोळा करतो (1,200 lookups)
1📣 एक तथ्य, अनेक ऐकणारे — notice service NoticePosted जाहीर करते, ती कोणालाही call करत नाहीnotice servicesave करते, मग publish करतेNoticePosted{id: "N-1", class: "3A", urgent: true}भूतकाळातील एक तथ्यbroker · topic(SNS / EventBridge / Kafka)✉️ emailemail पाठवते📱 SMSSMS jobs रांगेत टाकते (L07)🔎 search indexशब्द जोडते📊 analyticsसूचना मोजतेlistener जोडाहात न लावताnotice service लाप्रत्येक listeneridempotent असायला हवा:तोच eventदोनदा येऊ शकतोpublisher आणि listeners कधीचभेटत नाहीत: ते फक्त event वाटून घेतात2💥 dual write — मधेच crash झाल्यास event हरवतोसूचनासेवासूचना① save कराN-1 save झालीcrash!brokerकाहीच ऐकू येत नाही② publish — कधीच होत नाहीemail नाही, SMS नाही,search नोंद नाहीdual_write(crash) → ('notice saved', None)sheet मध्ये म्हटले होते: 'posted' सूचना कधीच हरवू नये — हे ते मोडते3📤 outbox — एकच transaction, publish नंतरBEGINCOMMIT — दोन्ही किंवा कोणतेच नाहीnotices: idclass · titleN-13A · सहलoutbox: eventसूचनाNoticePostedN-1publish करण्याआधीcrash→ save झाले, eventoutbox मध्ये थांबतोrelay (नंतर)readspublish करतो, मग sent म्हणून चिन्हांकित करतोbroker✓ NoticePostedrelay → published [('NoticePosted', 'N-1')]उशिरा पण कधीच हरवत नाही · relay दोनदा पाठवू शकतो → idempotent listeners4📨 fan-out — वर्ग 3A: 40 पालक, प्रत्येक 3 वर्ग follow करतो, दिवसाला 5 posts आणि 400 feed readsPUSH on write: प्रत्येक post प्रत्येक पालकाच्या inbox मध्ये copy कराwrites 200 (5 × 40)read lookups 400 (प्रत्येकी एक inbox)reads म्हणजे एक lookup — सामान्य लेखकांसाठी उत्तमPULL on read: एकदाच साठवा, पालक वाचतो तेव्हा गोळा कराpostएकदाच साठवले3A2B4Dwrites 5read lookups 1,200 (400 × 3 वर्ग)स्वस्त posts, महाग reads — 2M-follower लेखकासाठी हीच निवड (L17)
⏪ आधी

App सूचना save करी, मग broker ला सांगे; मधेच crash झाला तर NoticePosted हरवे आणि कोणत्याच पालकाला कळत नसे.

💡 काय

Event म्हणजे कार्यालयाची घोषणा: एक घटना, अनेक ऐकणारे; outbox म्हणजे पाठवेपर्यंत ठेवलेली चिठ्ठी.

⚙️ कसे

Outbox असेल तर crash नंतर NoticePosted थांबून राहते आणि relay ते publish करतो; push ला 200 writes, pull ला 1,200 lookups.

🎯 का

Database आणि broker मध्ये कोणताही event हरवत नाही, आणि email, SMS, search प्रत्येक स्वतंत्रपणे प्रतिसाद देतात.

🚀 पुढे

पुढचा धडा विचारतो एक deploy की अनेक: modular monolith ने सुरुवात करा आणि प्रत्येक hop ची किंमत मोजा.

🧪 इथे करून पाहा — DB आणि broker च्या मधे crash सह सूचना post करा — dual write विरुद्ध outbox; मग fan-out push विरुद्ध pull
4035400

पूर्ण धडा 08 वाचा →

9 🧩 Monolith vs microservices

modular monolith ने सुरुवात करा — प्रत्येक जास्तीच्या hop ची किंमत latency आणि availability मध्ये का मोजावी लागते, आणि कधी विभागायचे.

🧒 सोप्या शब्दांत

स्पष्ट टेबलांचे एक कार्यालय चालवायला सोपे असते. प्रत्येक टेबल वेगळ्या इमारतीत गेले, तर प्रत्येक प्रश्नासाठी फेरी मारावी लागते. प्रत्येक फेरीला वेळ लागतो आणि ती अपयशी होऊ शकते. सलग आठ फेऱ्यांनी page हळू आणि कमी भरवशाचे होते. म्हणून Dipika एका कार्यालयाने सुरुवात करते आणि खऱ्या कारणानेच टेबल बाहेर हलवते.

📖 नवे शब्दmodular monolith — आत स्पष्ट modules असलेला एक deploy; सुरक्षित सुरुवातmicroservice — एक team एकटी deploy करते अशी छोटी service, network वरून बोलावली जातेhop — एक network call; 20 ms चे 8 hops = 160 ms आणि 99.20% availabledistributed monolith — एकत्रच deploy कराव्या लागणाऱ्या अनेक services: सगळा खर्च, फायदा नाही
1🔗 प्रत्येक hop गुणाकार करतो — एका रांगेतील services मधून एक request, प्रत्येकी 20 ms आणि 99.9% availableappgateway99.9%1 hop20 ms0.999^1 = 99.90%≈ 30 दिवसांत 43 min बंदappgateway99.9%feed99.9%सूचना99.9%3 hops60 ms0.999^3 = 99.70%≈ 30 दिवसांत 2.2 h बंदappgateway99.9%feed99.9%सूचना99.9%classes99.9%पालक99.9%auth99.9%prefs99.9%i18n99.9%8 hops160 ms0.999^8 = 99.20%≈ 30 दिवसांत 5.7 h बंदlatency बेरीज होते, availability गुणाकाराने कमी होते — आणि प्रत्येक hop म्हणजे deploy, निरीक्षण आणि सुरक्षित करायची आणखी एक गोष्ट2🏢 MODULAR MONOLITH म्हणून सुरुवात करा — एकच इमारतसूचनाclassesपालकauthशोधसूचनाएकच deploy · in-process calls, network hop नाही · सोपे transactionsभिंती = module च्या सीमा: एखादी खोली दुसरी खोली फक्त तिच्या दारातूनच (API) वापरतेसूचनाएखादी खोली वेगळी काढाजेव्हा एखादी TEAM किंवाSCALING ची गरज मागणी करते(उदा. 5M SMS bursts)4 जणांची team → इथून सुरुवात करा3🏘️ microservices — रस्ते असलेले एक गावfeedसूचनाclassesपालकauthफोटो✓ प्रत्येक team स्वतंत्रपणे deploy करते, स्वतंत्रपणे scale होते, स्वतंत्रपणे बिघडते✗ प्रत्येक रस्ता म्हणजे एक network hop: latency, बिघाड, retries✗ data वेगवेगळ्या stores मध्ये विभागलेला — सोपे transactions नाहीत (L11)⛓️ सापळा: distributed monolithअनेक services ज्या एकत्रच deploy कराव्या लागतात — सगळा खर्च, फायदा काहीच नाही
⏪ आधी

Teams नी पहिल्याच दिवशी app चे डझनभर services केले, आणि तरीही ते सगळे एकत्रच deploy करावे लागले.

💡 काय

Modular monolith म्हणजे स्पष्ट टेबलांचे एक कार्यालय; team किंवा scale ची गरज असेल तेव्हाच service वेगळी करायची.

⚙️ कसे

प्रत्येक hop 20 ms आणि 99.9% up: 1 hop ला 99.90%, 3 hops ला 99.70%, आणि 8 hops ला 160 ms व फक्त 99.20%.

🎯 का

कमी hops म्हणजे जलद pages, जास्त availability आणि सोपे transactions, विभागण्याचे खरे कारण येईपर्यंत.

🚀 पुढे

पुढचा धडा प्रतींमध्ये एकमत ठेवतो: strong की eventual, R + W > N quorums आणि CAP ची निवड.

🧪 इथे करून पहा — services च्या रांगेतून जाणारी एक request — call_chain(hops, ms_each, availability_each)
32099.9

पूर्ण धडा 09 वाचा →

10 🔁 Consistency (सुसंगती)

Strong की eventual — replicas, quorums (R + W > N), read-your-writes आणि फूट पडल्यावर CAP ची निवड.

🧒 सोप्या शब्दांत

कार्यालय सूचना रजिस्टरच्या 3 प्रती ठेवते. शिक्षिका 'exam on Monday' बदलून 'Tuesday' करते, पण एक प्रत अजून बदललेली नाही. एकच प्रत पाहिली तर Monday वाचले जाऊ शकते. दोन पाहिल्या तर त्यातली एक नक्की Tuesday सांगते. गुणांसाठी पुरेशा प्रती तपासा; likes साठी एक पुरे.

📖 नवे शब्दstrong — प्रत्येक read नवीनतम write पाहतो; हळू पण नेहमी बरोबरeventual — प्रती थोड्या वेळाने जुळतात; एखादा read क्षणभर जुना असू शकतोquorum — R + W > N: 3 प्रती असताना 2 write आणि 2 read नेहमी एकमेकांना छेदतातCAP — network split च्या वेळी उत्तर द्या (कदाचित जुने) किंवा नकार द्या (बरोबर राहा)
1📒 एक सूचना, नोंदवहीच्या तीन प्रती (N = 3) — प्रत्येक प्रतीवर version शिक्का असतोप्रत Aसूचनांचीनोंदवहीपरीक्षासोमवारv7प्रत Bसूचनांचीनोंदवहीपरीक्षा पुढे ढकललीमंगळवारीv8प्रत Cसूचनांचीनोंदवहीपरीक्षासोमवारv7Katrinav8 लिहितेपरीक्षा पुढे ढकललीमंगळवारी✎ W = 1 — पहिली प्रत "saved" म्हणते, write पूर्ण झालेतुटक रेषा: B v8 ला A आणि C कडे copy करतेथोड्या वेळाने (replication lag)AishwaryaR = 1: A वाचते'परीक्षा सोमवारी'v7 — एक STALE (शिळे) readDipikaR = 2: A + B वाचते'परीक्षा मंगळवारी ढकलली'v7 विरुद्ध v8 → जास्त मोठा शिक्का जिंकतोquorum_read()R प्रतींना विचारा,त्यातील सर्वातजास्त version असलेली ठेवाv7v8<max((7, …), (8, …))→ v82⭕ R + W > N — तुम्ही READ केलेल्या प्रती आणि WRITE केलेल्या प्रती एकमेकांना भेटल्याच पाहिजेत (N = 3)R = 1 · W = 1v8v7v7✎ 1 लिहिली👁 1 वाचलीR + W = 2 ≤ 3eventual: कदाचितशिळी प्रत वाचली जाईल (★ नाही)R = 1 · W = 3v8v8v8★✎ 3 लिहिल्या👁 1 वाचलीR + W = 4 > 3strong: एकमेकांवर येतात★ = दोन्ही गटांत असलेली प्रतR = 2 · W = 2v8v8★v7✎ 2 लिहिल्या👁 2 वाचल्याR + W = 4 > 3strong: एकमेकांवर येतात★ = दोन्ही गटांत असलेली प्रतR = 3 · W = 1v8★v7v7✎ 1 लिहिली👁 3 वाचल्याR + W = 4 > 3strong: एकमेकांवर येतात★ = दोन्ही गटांत असलेली प्रत3✂️ network split — निवडा: उत्तर द्या की नकार द्याकार्यालय Aकडे v8 आहेकार्यालय Bकडे अजून v7संपर्क तुटलापरीक्षाकधी?एक पालक B ला विचारतात4⚖️ कोणते उत्तर, कोणत्या data साठीAP · उत्तर द्या (कदाचित शिळे)200 "परीक्षा सोमवारी"चालू राहते, चुकीचे असू शकतेlikes · view counts · feedsCP · नकार द्या (बरोबरच राहा)503 "थोड्या वेळाने पुन्हा प्रयत्न करा"कधीच चुकीचे नाही, कधी कधी बंदपैसे · गुण · जागाread-your-writes: Katrina स्वतःची सूचना वाचतेज्या प्रतीत तिने लिहिले (किंवा primary) तिथून, काही सेकंदांसाठीCAP: split च्या वेळी, consistency किंवा availability
⏪ आधी

Data ची एकच प्रत नेहमी बरोबर असे, आणि ती प्रत बंद पडली की पूर्ण app बंद पडे.

💡 काय

Consistency म्हणजे कार्यालय आपल्या 3 रजिस्टरमध्ये एकमत कसे ठेवते, म्हणजे पालक जुनी सूचना वाचत नाहीत.

⚙️ कसे

N=3 असताना R=1 W=1 'exam on Monday' वाचू शकते; R=2 W=2 एकमेकांना छेदतात आणि 'exam moved to Tuesday' वाचतात.

🎯 का

प्रत्येक data साठी निवडता: गुण आणि पैशांसाठी strong, थोडे मागे राहू शकणाऱ्या likes आणि counts साठी eventual.

🚀 पुढे

पुढचा धडा services मध्ये सगळे किंवा काहीच नाही करतो: two-phase commit, तो का अडतो, आणि undo करणारे sagas.

🧪 इथे करून पहा — सूचना नोंदवहीच्या N प्रती — R आणि W निवडा, नवीन version लिहा, मग वाचा आणि ते शिळे आहे का ते पहा
311

पूर्ण धडा 10 वाचा →

11 🤝 services ओलांडून transactions

services ओलांडून सगळे किंवा काहीच नाही — two-phase commit आणि ते का अडकते, compensations सह sagas.

🧒 सोप्या शब्दांत

शाळेच्या सहलीसाठी seat, payment आणि bus लागते. Katrina ची seat राखली जाते आणि ₹500 घेतले जातात. मग bus भरलेली निघते. म्हणून कार्यालय प्रत्येक पायरी उलट क्रमाने रद्द करते: Katrina ला ₹500 परत करते आणि seat मोकळी करते. प्रत्येक पायरीचा स्वतःचा undo असतो.

📖 नवे शब्द2PC — two-phase commit: सगळे मत देतात, मग सगळे commit; coordinator गेला तर BLOCKEDsaga — local पायऱ्यांची साखळी, पुढची अपयशी झाली तर प्रत्येकीला undocompensation — undo पायरी, जसे Katrina ला ₹500 परत करणेlock — data वरची पकड, तुमचे होईपर्यंत दुसरे कोणी बदलू शकत नाही
1🤝 two-phase commit — एक coordinator विचारतो, प्रत्येक service मत देते, मग प्रत्येक service पालन करतेतिन्ही होकारार्थी मत देतातcoordinatorजागापैसे भरणेबस① prepare? (तयार?)② मतCOMMIT③ तिघांनाही "commit" — सहल बुक झालीएकच transaction असल्यासारखे दिसतेबस नकारार्थी मत देतेcoordinatorजागापैसे भरणेबस① prepare? (तयार?)② मतABORT③ तिघांनाही "abort" — काहीच ठेवले जात नाहीएक नकार पुरेसा: सगळे किंवा काहीच नाही"prepare" नंतर coordinator बंद पडतोcoordinator💥 कोसळलाजागापैसे भरणेबस① prepare? (तयार?)② मत❄❄❄अडकले (BLOCKED)प्रत्येक service ने होकार दिला, आपली row lock केलीआणि वाट पाहते — कोणीही commit म्हणू शकत नाही2🧾 saga — क्रमाने local पायऱ्या; एखादी अयशस्वी झाली, तर पूर्ण झालेल्या उलट क्रमाने undo करावेळ1✓ जागा राखून ठेवाseats service2✓ Katrina कडून ₹500 घ्याpayment service₹3✗ बस बुक कराबस भरली आहे4↩ Katrina ला ₹500 परत कराcompensation (एक नवीन local पायरी)5↩ जागा मोकळी कराcompensation (एक नवीन local पायरी)बस रद्द करा — गरज नाहीअयशस्वी पायरीने मागे काहीच सोडले नाही① undo करते② undo करतेअपयश आल्यासCOMPENSATEDKatrina ला तिचे₹500 परत मिळाले, जागामोकळी आहे — शेवटी,सुसंगत (consistent)नोंद: ✓ जागा राखून ठेवा · ✓ Katrina कडून ₹500 घ्या · ✗ बस बुक करा · ↩ Katrina ला ₹500 परत करा · ↩ जागा मोकळी करा3🔒 2PC — सगळे एकाच वेळी✓ सगळे किंवा काहीच नाही — एकच transaction असल्यासारखे दिसते✗ coordinator बंद पडल्यास अडकते; services ओलांडून locks धरून ठेवले जातात→ एकाच database cluster मध्ये / घट्ट जोडलेल्या resources साठी4↩ saga — पायरी पायरीने, undo सह✓ global locks नाहीत — प्रत्येक service स्वतंत्र राहते✗ मधल्या अवस्था दिसतात; प्रत्येक पायरीला undo हवे→ microservices ओलांडून: bookings, orders, payments
⏪ आधी

एकाच database मध्ये सगळे असे, म्हणून एक transaction पुरे; services वेगळे झाले आणि bookings अर्धवट राहू लागली.

💡 काय

Saga म्हणजे कार्यालयाची सहलीची यादी: प्रत्येक पायरीला undo असतो, म्हणून अपयशी पायरीनंतर क्रमाने मागे जाता येते.

⚙️ कसे

Coordinator गेला तर 2PC BLOCKED होतो; saga seat राखते, Katrina ला ₹500 लावते, bus भरली, ₹500 परत करते.

🎯 का

Services मध्ये global locks नाहीत, आणि अर्धवट अपयश स्वच्छ संपते: Katrina ला पैसे परत मिळतात आणि seat मोकळी होते.

🚀 पुढे

पुढचा धडा कार्यालयाला पुरापासून वाचवतो: token bucket vs sliding window, प्रत्येक user साठी आणि एकूण.

🧪 इथे करून पहा — शाळेच्या सहलीचे booking — two-phase commit मध्ये मत द्या, coordinator बंद पाडा, मग saga ची कोणतीही पायरी अयशस्वी करा
2PCsaga

पूर्ण धडा 11 वाचा →

12 🚦 Rate limiting

कार्यालयाला लोंढ्यांपासून वाचवा — token bucket vs sliding window, प्रति user, प्रति key, जागतिक पातळीवर.

🧒 सोप्या शब्दांत

प्रत्येक पालकाच्या app ला canteen coupons सारखे tokens मिळतात. प्रत्येक request एक वापरते, आणि दर सेकंदाला थोडे परत मिळतात. Aishwarya चा phone अडकला आणि अर्ध्या सेकंदात 17 requests पाठवल्या. Bucket ने 12 आत सोडल्या आणि बाकीच्यांना 'हळू' सांगितले. बाकी सगळ्यांना सेवा मिळत राहिली.

📖 नवे शब्दtoken bucket — tokens ठराविक वेगाने भरतात आणि burst ची सूट: 5/s, burst 10sliding window — प्रत्येक कालावधीची पक्की मोजणी: 1 s ला 10, म्हणून 17 पैकी 10 जातात429 — 'खूप जास्त requests' हे उत्तर, Retry-After सोबत पाठवलेलेburst — नेहमीच्या वेगापेक्षा जास्त, थोड्या वेळासाठी परवानगी असलेली गर्दी
1🪣 token bucket — दर सेकंदाला 5 tokens, 10 ची जागाt = 0 s: भरलेली+5/s10 tokensbucket भरलेली आहे:10 पर्यंतचा burstएकदम जाऊ शकतो- - = burst 100 s ला 12 येतात+5/s0 tokens उरले10 ना token मिळतो2 → 429t = 0.5 s: +2.5 tokens+5/s2.5 tokens2 ना token मिळतो3 → 4292🪟 sliding window — कोणत्याही 1 सेकंदात जास्तीत जास्त 10t = 0.5 s ला window1 s मागे पाहते: (−0.5 s, 0.5 s]t = 1.0 s ला पहिले 10बाहेर सरकतात: पुन्हा जागा-0.5 s0 s0.5 s1 s1.5 s12510 / 100.5 s ला window मध्ये अजून पहिले 10 आहेत → सर्व 5 नाकारलेप्रत्येक कालावधीसाठी पक्की मोजणी — मधे refill नाहीपरवानगीनाकारले3🚦 तोच burst, दोन नियम — 0 s ला 12 requests, मग 0.5 s ला आणखी 5token bucket5/s, burst 1042942942942942917 पैकी 12sliding window1 s मध्ये 1042942942942942942942917 पैकी 10t = 0 s (12)t = 0.5 s (5)bucket ने 0.5 s मध्ये 2.5 tokens refill केले, म्हणून आणखी 2 आत गेले; window मात्र t = 1.0 s पर्यंत पहिले 10 मोजत राहते4🧱 हे कुठे चालते — प्रत्येक user, प्रत्येक API key आणि global पातळीवर, counters Redis मध्ये, 429 + Retry-Afterपालकांचे apps + एक गोंगाट करणारी scriptAPI gatewayप्रत्येक user साठी, उदा. 10 / sप्रत्येक API key साठी, उदा. 100 / sglobal, उदा. 5,000 / sRedisसामायिक countersपरवानगीसूचना APIमर्यादेपलीकडेHTTP 429 Too ManyRetry-After: 1"हळू घ्या, 1 s नंतर प्रयत्न करा"कोणता नियम कधी?🪣 token bucketस्थिर दर + एक burstसवलत — apps साठी चांगले🪟 sliding windowप्रत्येक कालावधीसाठी पक्की मोजणी —quotas आणि logins साठी चांगलेदोघेही आपले counters Redis मध्ये ठेवतात
⏪ आधी

एक सदोष app सतत requests पाठवून बाकी सगळ्या पालकांसाठी कार्यालय मंद करू शकत असे.

💡 काय

Rate limiting म्हणजे कार्यालयाची token खिडकी: प्रत्येक पालकाला tokens मिळतात, token नसेल तर उत्तर 429.

⚙️ कसे

0.5 s मध्ये 17 requests: token bucket (5/s, burst 10) 12 आत सोडतो, sliding window (10 per 1 s) फक्त 10.

🎯 का

एक गोंगाट करणारे app बाकीच्यांना उपाशी ठेवू शकत नाही; त्याला Retry-After सह 429 मिळतो, counters Redis मध्ये.

🚀 पुढे

पुढचा धडा भाग 3 उघडतो: प्रत्येक dependency अपयशी होते, म्हणून page budget मध्ये प्रत्येकाला timeout द्या.

🧪 इथे करून पहा — burst बदला (count@second, किंवा count@start-end समान वाटून) आणि दोन्ही limiters ची तुलना करा
🪣 token bucket510🪟 sliding window101

पूर्ण धडा 12 वाचा →

13 🛟 रचनेतच लवचिकता (resilience)

प्रत्येक dependency बिघडते — timeout budgets, jitter सह retries, breakers, degradation, multi-AZ.

🧒 सोप्या शब्दांत

Page 800 ms मध्ये तयार हवे. Dipika त्यातच प्रत्येक मदतनीसाला वेळमर्यादा देते: 50 ms, 150 ms आणि 300 ms. Photo मदतनीस नसला तरी page सूचना दाखवते, फक्त photos शिवाय. सतत अपयशी होणाऱ्या मदतनीसाला कार्यालय बोलावणे थांबवते, आणि नंतर पुन्हा प्रयत्न करते.

📖 नवे शब्दtimeout — पुढे जाण्याआधी मदतनीसासाठी थांबायची जास्तीत जास्त वेळretry with jitter — थोडा random वेळ थांबून पुन्हा प्रयत्न, म्हणजे सगळे एकदम retry करत नाहीतcircuit breaker — अपयशी भागाला काही वेळ बोलावणे थांबवा, मग पुन्हा तपासाdegrade — तुटलेल्या भागाशिवाय page चालू ठेवा, जसे photos शिवाय सूचना
1⏱️ timeout चे बजेट — पानाकडे 800 ms आहेत; प्रत्येक dependency ला स्वतःचा वाटा800 msसूचनांचा DBtimeout 150 msफोटो servicetimeout 300 msauth 50 msखुद्द पानासाठी उरलेलेrender + network: 300 ms0100200300400500600700800ms800 ms च्या पानात 500 ms dependencies ना — हळू भाग कापला जातो, त्याची वाट पाहिली जात नाहीtimeout नाही = सर्वात हळू dependency इतका वेळ पान वाट पाहते (30 s हा नेहमीचा default असतो)2🖼️ फोटो service बंद आहे — फोटोशिवाय सूचना दाखवा (degrade), पान अपयशी करू नकाफोटो serviceबंदbreakerOPEN (उघडा)लवकर अपयशी व्हा (fail fast)jitter सह retries — पसरलेले, लाटांमध्ये नाहीjitter नाहीपूर्ण jitterतेच retries, उसळ्यांऐवजी सपाट भारयोजनेशिवायफोटोंची वाट पाहत आहे…30 s नंतर:504 · सूचना नाहीतएक भाग मोडला, पानच नाहीरचनेतच—मंगळवारी परीक्षा—क्रीडा दिनाचा गणवेश—सहल: ₹500 भराफोटो लवकरच परत येतील800 ms च्या बजेटमध्येनिरोगीमंगळवारी परीक्षाक्रीडा दिनाचा गणवेशसहल: ₹500 भरासूचना + फोटोकमी क्षमतेने चालू, बंद नाही (DEGRADED, NOT DOWN)3🏢 एकापेक्षा जास्त Availability Zone मध्ये प्रती — कोणतीही एक प्रत चालू असेल तर सेवा चालूएक AZ99.5%≈ दर 30 दिवसांत 3.6 h बंद→AZ aAZ bAZ cतीन AZs: 99.99999%≈ दर 30 दिवसांत 0.3 s बंद — एक AZ जळून गेला तरी कोणाला कळत नाहीचालू = 1 − (1 − 0.995)³ = 1 − 0.000000125 = 99.99999%फक्त AZs स्वतंत्रपणे अपयशी झाले तरच —सामायिक config, एकच region किंवा एक चुकीचा deployतरीही तिन्ही एकत्र बंद पाडतात
⏪ आधी

एक हळू photo service उत्तर देईपर्यंत प्रत्येक page अडवून ठेवे, म्हणून छोट्या दोषाने पूर्ण app बंद पडे.

💡 काय

Resilience म्हणजे कार्यालयाची प्रत्येक टेबलाची पर्यायी योजना: ठराविक वेळच थांबा, हळूवार retry करा, त्याशिवाय काम चालू ठेवा.

⚙️ कसे

800 ms चे page budget: auth 50 ms, notices DB 150 ms, photos 300 ms; photos बंद तर photos शिवाय सूचना.

🎯 का

अपयशी भाग एक feature घालवतो, page नाही; breaker थांबलेला असताना पालक सूचना वाचत राहतात.

🚀 पुढे

पुढचा धडा विचारतो कोण काय करू शकतो: प्रत्येक box ला STRIDE, आणि प्रत्येक object साठी authorization.

🧪 इथे करून पाहा — 800 ms चे पानाचे बजेट auth, सूचनांचा DB आणि फोटो service मध्ये वाटा — मग फोटो service मोडून पाहा
8005015030012099.53

पूर्ण धडा 13 वाचा →

14 🔐 रचनेतच सुरक्षा

प्रत्येक box ला STRIDE विचारा — identity, प्रत्येक object साठी authorization, encryption, secrets, गैरवापर.

🧒 सोप्या शब्दांत

नवी इमारत उघडण्याआधी कोणीतरी फिरून प्रत्येक दार आणि खिडकी तपासते. Dipika योजनेचे तेच करते. प्रत्येक box ला ती 6 प्रश्न विचारते: कोण बोलावतो, बदलले का, नाकारता येईल का, कोण वाचू शकते, पूर येईल का, कोणी boss होऊ शकतो का. पालकांना फक्त आपल्या मुलांचे वर्ग दिसतात.

📖 नवे शब्दSTRIDE — धोक्यांचे 6 प्रश्न: Spoofing, Tampering, Repudiation, Info, DoS, Elevationauthentication — तुम्ही कोण आहात ते सिद्ध करणे, उदाहरणार्थ OIDC नेauthorization per object — प्रत्येक सूचनेसाठी हा पालक ती वाचू शकतो का ते तपासणेleast privilege — प्रत्येक भागाला खरोखर लागते तेवढाच access द्या
1🛡️ STRIDE — आकृतीतील प्रत्येक खोक्याला विचारायचे सहा प्रश्न (इथे: सूचना API)सूचना APIPOST /noticesGET /feedS T R I D Eप्रत्येक अक्षरासाठी एक प्रश्नSSpoofingखरोखर कोण call करत आहे?→ authentication (OIDC, mTLS, सही केलेल्याrequests)उदा. बनावट app शिक्षक म्हणून सूचना टाकतेTTamperingवाटेत किंवा साठवलेले असताना ते बदलले गेले का?→ TLS, सह्या, checksums,किमान-अधिकार writesउदा. API आणि DB च्या दरम्यान सूचना बदलली जातेRRepudiationकोणी ते केल्याचे नाकारू शकेल का?→ ज्या audit logs ते बदलू शकत नाहीत (CloudTrail,append-only)उदा. "मी ती सूचना कधीच delete केली नाही"IInformation disclosureते कोण वाचू शकते?→ encryption, प्रत्येक object साठी authorization,logs मध्ये secrets नाहीतउदा. एक पालक दुसऱ्या वर्गाच्या सूचना वाचतातDDenial of serviceत्यावर पूर आणता येईल का?→ rate limits, WAF, quotas, कमाल मर्यादेसहautoscalingउदा. एक script POST /notices वर पूर आणतेEElevation of privilegeसाधा user admin बनू शकतो का?♛→ किमान अधिकार, input validation,isolation (अलगीकरण)उदा. एक पालक फक्त-शिक्षकांसाठीचा endpoint call करतात2🚧 trust boundary (विश्वासाची सीमा) — बाहेरचे सर्व अविश्वसनीयपालकांचे appinternettrust boundaryTLSgatewayWAF · limitstoken तपासणीसूचना APIसूचनाencryptedतिजोरीsecrets इथेराहतात, code मध्ये नाहीAPI आपला DB password vault मधून वाचतेaudit log (append-only): कोणी post केले, कोणी delete केले, कधीPII (नावे, फोन नंबर) encrypted · logs मध्ये secrets नाहीत3🔑 प्रत्येक object साठी authorizationAishwarya3A मधील मूलवर्ग 3A200 OKतिच्या मुलाचा वर्गवर्ग 5B403तुमचा वर्ग नाहीlogged in ≠ परवानगी: वर्ग तपासाप्रत्येक request वर, फक्त login च्या वेळी नाही
⏪ आधी

Security म्हणजे launch आधीचा एक checkbox, म्हणून पालक class id ओळखून दुसऱ्या वर्गाच्या सूचना वाचू शकत.

💡 काय

Security by design म्हणजे कार्यालयाची कुलपांची यादी: बांधण्याआधी योजनेतील प्रत्येक box ला STRIDE विचारा.

⚙️ कसे

Notice API ला STRIDE चे 6 प्रश्न, spoofing पासून elevation पर्यंत; पालकांना फक्त आपल्या मुलांचे वर्ग दिसतात.

🎯 का

धोके कागदावरच सापडतात, जिथे दुरुस्ती स्वस्त: auth, audit logs, encryption, rate limits, least privilege.

🚀 पुढे

पुढचा धडा launch आधी निरोगी म्हणजे काय ते ठरवतो: SLOs, error budgets, RED, USE आणि traces.

🧪 इथे करून पाहा — आकृतीतील एक खोका निवडा (किंवा टाइप करा) — त्याला STRIDE विचारा आणि ज्या धोक्यासाठी तुमची योजना आहे त्यावर खूण करा

पूर्ण धडा 14 वाचा →

15 📈 रचनेतच observability

launch आधीच निरोगी म्हणजे काय ते ठरवा — SLOs, error budgets, RED आणि USE, logs, metrics, traces.

🧒 सोप्या शब्दांत

Check-up आधी डॉक्टर ठरवतात की निरोगी म्हणजे काय. Dipika ते launch आधी ठरवते: 99.9% requests चालायला हव्यात. त्यामुळे महिन्याला 43 मिनिटांची अडचण चालते, हेच error budget. पालकांना त्रास जाणवतो तेव्हा alarm वाजतो, फक्त machine व्यस्त असताना नाही.

📖 नवे शब्दSLO — दिलेले उद्दिष्ट, जसे 99.9% requests चालणेerror budget — SLO किती अपयश चालू देते: 30 दिवसांत 43.2 मिनिटेRED — प्रत्येक API साठी: Rate, Errors, Durationtrace — एका request चा तिने स्पर्श केलेल्या प्रत्येक service मधून घेतलेला माग
1🎯 SLO चे रूपांतर error budget मध्ये होते — 30 दिवसांत तुम्हाला अपयशी होण्याची परवानगी असलेली मिनिटे99%2 nines432.0मिनिटे / 30 दिवस≈ 7.2 तास30 दिवस, बजेट लाल रंगात:(1 − 0.99) × 30 × 24 × 60 = 432.099.9%3 nines43.2मिनिटे / 30 दिवस≈ 43 मिनिटे30 दिवस, बजेट लाल रंगात:(1 − 0.999) × 30 × 24 × 60 = 43.299.99%4 nines4.3मिनिटे / 30 दिवस≈ 4 मिनिटे30 दिवस, बजेट लाल रंगात:(1 − 0.9999) × 30 × 24 × 60 = 4.3बजेट releases आणि प्रयोगांवर खर्च करा — ते संपले की features थांबवा आणि विश्वसनीयता दुरुस्त करा2🔴 RED — प्रत्येक API साठी (पालकांना जे जाणवते)Raterequests / sErrors% अपयशीDurationp99 ms विरुद्ध 200 msSLO3🟣 USE — प्रत्येक resource साठी (इथे: सूचनांचा DB)Utilisationकिती व्यस्त (CPU, IO)70% व्यस्तSaturationकिती वाट पाहत आहेरांगेतील queriesErrorsresource अपयशी होणेdeadlock ×2conn refused ×1disk full ×0मोजलेले, दुर्लक्षित नाहीerrors आणि duration मध्ये उसळी — पालकांना हे जाणवतेRED सांगते काहीतरी चुकले आहे; USE सांगते कोणता खोका4🧵 logs, metrics, traces — एक request id त्यांना जोडतो; alert SLO वर द्या, CPU वर नाहीlogs · request id सह12:01:07 INFO req=7f3a POST /notices class=3A user=t-18 201 in 142 ms12:01:08 WARN req=7f3b GET /feed photo service timeout 300 ms12:01:08 INFO req=7f3b 200 degradedlogs: एका request चे काय झालेtrace req=7f3b — वेळ कुठे गेलापानauthसूचनांचा DBफोटो service300 ms ला कापले0500 mstraces: services ओलांडून एक request📟 माणसाला page करा जेव्हा…✓ error budget वेगाने जळत असेल(उदा. महिन्याचा 10% एका तासात)✗ "CPU 80% वर" नाही— CPU कोणालाच जाणवत नाहीmetrics: काळानुसार आकडे
⏪ आधी

रात्री जास्त CPU वर alerts वाजत पण पालकांना काही त्रास नसे, आणि खरे outages तासनतास लक्षात येत नसत.

💡 काय

Observability म्हणजे कार्यालयाचा आरोग्य तक्ता: निरोगी म्हणजे काय ते ठरवा, मग rate, errors आणि वेळ पाहा.

⚙️ कसे

99.9% SLO मुळे 30 दिवसांत 43.2 मिनिटांचे error budget मिळते; 99.99% ला फक्त 4.3 मिनिटे.

🎯 का

Alert पालकांना जाणवते त्यावर, CPU वर नाही, आणि budget सांगते कधी ship करायचे आणि कधी थांबायचे.

🚀 पुढे

पुढचा धडा प्रत्येक box ला बिल आणि कारण देतो: पहिला cost model आणि एका पानाची निर्णयाची नोंद.

🧪 इथे करून पाहा — SLO चे error budget मध्ये रूपांतर करा — मग ते incidents वर खर्च करा आणि किती उरते ते पाहा
30

पूर्ण धडा 15 वाचा →

16 💰 खर्च, देवाणघेवाण (trade-offs) आणि ADRs

प्रत्येक box ला एक बिल आणि एक कारण असते — पहिले cost model आणि एका पानाची निर्णयाची नोंद (ADR).

🧒 सोप्या शब्दांत

योजनेतल्या प्रत्येक box चे बिल असते: servers, storage, बाहेर पाठवलेला data, requests. Dipika बेरीज करते: महिन्याला $1,216. मग Redis का निवडले आणि त्याची किंमत काय, हे ती एका पानावर लिहिते. पुढच्या वर्षी नवी सहकारी वाद पुन्हा सुरू करण्याऐवजी ते पान वाचते.

📖 नवे शब्दcost model — प्रत्येक box चे बिल एकत्र: इथे महिन्याला $1,216egress — users कडे बाहेर पाठवलेला data; अनेकदा सर्वात मोठी ओळ, इथे $450trade-off — देवाणघेवाण (trade-off): एक मिळवता, दुसऱ्याने किंमत मोजता, जसे वेगासाठी 60 s उशीरADR — एका पानाची निर्णयाची नोंद (ADR): संदर्भ, निर्णय, परिणाम
1🧾 सूचना फलकाचे पहिले बिल (उदाहरणादाखल किमती)नियोजन कार्यालय · मासिक बिलसूचना फलक, एक महिनाservers6 × $60 / महिना$360.00storage2,000 GB × $0.023$46.00egress5,000 GB × $0.09$450.00requests900 M × $0.40$360.00एकूण$1,216.00किमती गोल उदाहरणे आहेत —खरी pricing पाने तपासापैसा कुठे जातो37.0%egress29.6%servers29.6%requestsstorage 3.8%egress (cloud बाहेर जाणारा data) ही सर्वात मोठी ओळ, storage सर्वात लहान —CDN किंवा cache हा बहुतेकदा खर्चाचा निर्णय असतो, फक्त वेगाचा नाही2📄 लिहून ठेवलेला निर्णय — ADR# ADR 001: वर्गाचीfeed Redis मध्ये cache करास्थिती: स्वीकृतस्वीकृत## संदर्भReads हे writes च्या 100x; p993x peak ला 200 ms खाली राहिला पाहिजे.## निर्णयप्रत्येक वर्गासाठी cache-aside, TTL 60 s,post केल्यावर delete.## परिणाम- ~95% reads database टाळतात- एखादी सूचना काही वाचकांना60 s पर्यंत उशिरा दिसू शकते- चालवायची आणखी एक गोष्टएक पान · क्रमांकित · कधीही बदलले जात नाही — नवीन ADR जुन्याची जागा घेतो"का" हे उत्तर निर्णय घेणाऱ्या लोकांनंतरही टिकतेतारखा, लेखक आणि तुम्ही नाकारलेले पर्यायही मदत करतातADR 001ADR 002ADR 003repo मधील docs/adr/,code च्या शेजारी,code प्रमाणेच review केलेले3⚖️ प्रत्येक निर्णय ही देवाणघेवाण (trade-off) असते — दोन्ही बाजू लिहाफायदे~95% readsDB टाळतातखर्च≤ 60 s जुने (stale)चालवायची आणखी एक गोष्ट4🏷️ प्रत्येक box ला बिल आहे आणि कारणहीCDN$ egress ↓पालकांजवळ photosAPI × 6$3603x peak + राखीव जागाRedis$ कमीADR 001Postgres$ storageसुरक्षित पर्याय (L04)ज्या box चे कारण कोणीच सांगू शकत नाही, त्यावरच सर्वात आधी प्रश्न विचारा
⏪ आधी

Redis का आहे किंवा app ला किती खर्च येतो कोणालाच माहीत नसे, म्हणून प्रत्येक नवा माणूस तोच वाद पुन्हा घाले.

💡 काय

Cost model आणि ADR म्हणजे कार्यालयाचे बिल आणि इतिवृत्त: प्रत्येक box ला किती खर्च आणि तो का निवडला.

⚙️ कसे

पहिले बिल: servers $360, storage $46, egress $450, requests $360, एकूण $1,216; ADR 001 feeds Redis मध्ये cache करतो.

🎯 का

प्रत्येक देवाणघेवाण (trade-off) परिणामांसह एकदाच लिहिली जाते, म्हणून नंतरच्या teams जाणीवपूर्वक ठेवतात किंवा बदलतात.

🚀 पुढे

पुढचा धडा पूर्ण पद्धत तीन classic designs वर वापरतो: URL shortener, notifications आणि chat.

🧪 इथे करून पाहा — पहिले मासिक बिल — आकार आणि उदाहरणातल्या किंमती बदला; मग ती निवड समजावणारी ADR लिहा
620005000900

संपूर्ण धडा 16 वाचा →

17 ✏️ सोडवलेल्या रचना: URL shortener · notifications · chat

तीन क्लासिक रचना, त्यांना आकार देणारे आकडे — short ids, fan-out, connections आणि ordering.

🧒 सोप्या शब्दांत

आता Dipika त्याच यादीने तीन प्रसिद्ध apps आखते. Short links: 6 billion links साठी 6 अक्षरे पुरतात. Notifications: साध्या शिक्षिका प्रत्येक inbox मध्ये push करतात, पण 2 million followers असलेल्या star चे वाचताना आणले जाते. Chat: 1 million online लोकांसाठी 20 gateway servers लागतात.

📖 नवे शब्दbase62 — 0-9, a-z, A-Z: 6 अक्षरांतून 62^6 ≈ 56.8 billion ids301/302 — browser ला लांब link कडे पाठवणारी redirect उत्तरेWebSocket — उघडे ठेवलेले connection, म्हणजे chat messages लगेच पोहोचतातsequence number — प्रत्येक message वरचा क्रमांक, म्हणजे ते योग्य क्रमाने दिसतात
1🔗 URL shortener — महिन्याला 100M नवीन links, प्रत्येक 100 वेळा वाचली जाते39writes / s3,858reads / s11,690peak वर req/s (×3)6 अक्षरे5 वर्षांत 6,000,000,000 idsएक पालक click करतात/6y3o5xLBapp serversread मार्गcachehot codesmisskey-valuecode → URL301 / 302 redirect → मूळ लांब URLwrite मार्गid generatorbase62()किती अक्षरे?662y62362o62562x6262 × 62 × 62 × 62 × 62 × 62 = 62⁶ ≈ 56.8 अब्ज≥ 6,000,000,000 ids हवेत → 6 अक्षरे पुरेशीbase62(5,999,999,999) = "6y3o5x"5 वर्षांतला शेवटचा id सुद्धा 6 मध्ये बसतोअक्षरमाला: 0-9 a-z A-Z2📣 notifications — write वेळी inboxes मध्ये push करा, पण लेखक celebrity असेल तर followers स्वतः pull करतातएक शिक्षिका300 followerswrite वेळी push: दिवसातून 3 posts300 followers × 3 posts = दिवसाला 900 inbox writesएक read = एक inbox lookup — वेगवान feedsread वेळी pull: 2,000,000 followers★एक celebrityतिच्या postsएकदाच साठवले… 2M वाचकप्रत्येक post मागे 2M inbox writes टळले → 0 inbox writesप्रत्येक follower वाचताना तिच्या posts गोळा करतो (hybrid ≥ 100,000)3💬 chat — 1M online, प्रत्येक gateway server वर 50k WebSocket connections, sequence number नुसार क्रम1,000,000 onlineप्रत्येकाकडे 1 socket20 gateway servers1M ÷ 50,000संदेशसेवाप्रत्येक chat चा seqसंदेश463msg / s8.0 GBएका दिवसात (प्रत्येकी 200 B)1M × दिवसाला 40 संदेश ÷ 86,400 sgateways फक्त sockets धरून ठेवतात;presence table सांगते की कोणता gatewayकोणत्या user ला धरून आहे, म्हणजे संदेशयोग्य gateway कडे पोहोचवता येतोपोहोचण्याचा क्रम ≠ पाठवण्याचा क्रमsee you3hi1hello2जसे पोहोचले तसेsorthi1hello2see you3(chat 3A, seq) नुसार['see you', 'hi', 'hello'] → ['hi', 'hello', 'see you']server प्रत्येक chat साठी एक क्रमांक लावतो;phones वरच्या घड्याळांवर विश्वास ठेवता येत नाही
⏪ आधी

Classic designs चित्रांसारखी पाठ केली जात, म्हणून आकड्यांत छोटा बदल झाला की design समजावता येत नसे.

💡 काय

Worked designs म्हणजे कार्यालय आपली यादी सुरुवातीपासून शेवटपर्यंत वापरते: दर वेळी आकडे आकार ठरवतात.

⚙️ कसे

6 billion links ला 6 base62 अक्षरे पुरतात; 2M followers च्या लेखकासाठी pull; 1M online chat ला 20 gateways.

🎯 का

प्रत्येक box एका आकड्यावरून समजावता येतो, म्हणून नवे काम अंदाज न राहता design बनते.

🚀 पुढे

पुढचा धडा तीन जड designs घेतो: chunks सह file storage, CDN सह video, आणि AI search साठी RAG.

🧪 इथे करून पाहा — तीन calculators — URL shortener, notification fan-out आणि chat service — आणि sequence number नुसार क्रम लावणे
🔗1001005📣3💬5040200

संपूर्ण धडा 17 वाचा →

18 🎬 सोडवलेल्या रचना: file storage · video · RAG

तीन जड रचना — chunks आणि dedupe, renditions आणि CDN egress, AI search साठी ingest vs ask.

🧒 सोप्या शब्दांत

मोठ्या files चे तुकडे केले जातात, म्हणून एक शब्द बदलला तर 12 पैकी फक्त 2 तुकडे upload होतात. Video 4 आकारांत ठेवला जातो, आणि तो पाहणाऱ्यांकडे पाठवणे ठेवण्यापेक्षा खूप महाग असते. AI search साठी शाळेचे documents आधीच 400,000 छोटे तुकडे होतात. प्रश्न सर्वोत्तम 5 शोधतो आणि sources सह उत्तर देतो.

📖 नवे शब्दchunk — content hash ने नाव दिलेला file चा तुकडा; सारखा तुकडा एकदाच साठवला जातोrendition — video चा एक आकार: 1080p, 720p, 480p किंवा 240pCDN egress — CDN कडून पाहणाऱ्यांकडे गेलेला video: 1M views साठी 187.5 TBRAG — आधी योग्य chunks शोधा, मग AI ला त्यांतून sources सह उत्तर देऊ द्या
1🗂️ file storage — chunks मध्ये विभागा, प्रत्येक chunk ला त्याच्या content hash चे नाव द्या, फक्त नवीन असलेलेच upload करापहिली आवृत्ती12 chunks × 4 अक्षरे"the·"6e5ce6af"scho"f989dfc1"ol·a"290ffb88"nnua"4bb45c7c"l·re"ad62abcd"port"f8d397a3"·for"a3fa3964"·202"0755a850"6·ve"f164341b"rsio"bf982e5b"n·on"2637f86b"e"3f79bb7bदुसरी आवृत्ती12 chunks × 4 अक्षरे"the·"6e5ce6af"scho"f989dfc1"ol·a"290ffb88"nnua"4bb45c7c"l·re"ad62abcd"port"f8d397a3"·for"a3fa3964"·202"0755a850"6·ve"f164341b"rsio"bf982e5b"n·tw"3a34664e"o"65c74c15एक शब्द बदलला → 2 नवीन hashesmetadatafile v2 = [6e5ce6af, f989dfc1, … 3a34664e, 65c74c15]मालक कोण, कोणते chunks, कोणती आवृत्ती — database मध्येबाकीचे 10 आधीच साठवलेले आहेत —dedupe फुकट: सारखा content = सारखे नाव12 पैकी 2 chunks upload कराchunksobjectstorage2🎬 video — एका upload मधून 4 renditions होतात; बिल storage चे नाही, CDN चे येतेएक शिक्षिका upload करते1 मिनिटrawtranscodeworkers (queue)1080p5 Mb/s720p2.5 Mb/s480p1 Mb/s240p0.3 Mb/sबेरीज 8.8 Mb/s × 60 s ÷ 8 = 66 MB→ प्रति मिनिट 0.07 GB साठवलेप्रेक्षकांजवळ CDN edges1M views × 10 minदर महिन्याला, एका लोकप्रिय video साठी:साठवलेले10 मिनिटांचा video: 0.66 GB, एकदाच साठवलाCDN egress1M × 10 min × 60 s × 2.5 Mb/s ÷ 8 = 187.5 TB3🔎 शाळेच्या documents वर RAG — ingest offline चालते, ask online चालतेINGEST · offline, प्रत्येक नवीन document साठी एकदा10,000 docs× 20 पानेchunk (250 शब्द)400,000 chunksembed1,024 संख्याvector index ~1.64 GB400,000 × 1,024 × 4 bytes ≈ 1.64 GBingest: chunk → embed → index — जड, batch,offline; document बदलला की पुन्हा चालवाask: प्रश्नाचे embed → जवळचे 5 → prompt →sources सह उत्तर — वेगवान, प्रत्येक प्रश्नाला, onlineASK · online, प्रत्येक प्रश्नAishwarya विचारते:क्रीडा दिन कधी आहे?प्रश्नाचे embedजवळचे 5 chunksk-NN searchशोधpromptप्रश्न 505 chunks × 325 = 1,625≈ 1675 tokensLLMchunks वाचतो"क्रीडा दिन14 Nov, सकाळी 9 वाजता आहे."स्रोत: circular-12प्रश्न 50 tokens + 5 × (250 शब्द × 1.3) = 1675 · उदाहरणातले उत्तर आणि स्रोत काल्पनिक आहेत
⏪ आधी

जड designs चा खर्च फक्त storage वरून काढला जाई, आणि खरे बिल, uploads आणि CDN egress, धक्का देऊन येई.

💡 काय

जड designs म्हणजे कार्यालयाच्या सर्वात मोठ्या योजना: files चे chunks, videos चे renditions, RAG साठी documents.

⚙️ कसे

एक शब्द बदलला तर 12 पैकी 2 chunks upload; 1M video views म्हणजे 187.5 TB CDN egress; RAG 400,000 chunks index करते.

🎯 का

तीच पद्धत कोणत्याही आकारात चालते: गरजा, आकडे, API, data, blocks, failure, security, cost, ADR.

🚀 पुढे

पुढे कुठे: traffic साठी Scaling school, data साठी Database school, आणि RAG साठी AI school.

🧪 इथे करून पाहा — तुम्ही बदललेली file chunk + dedupe करा, video ladder आणि त्याचे CDN बिल मोजा, आणि RAG index व prompt चा आकार काढा
🗂️4🎬1102.5🔎20500250550

संपूर्ण धडा 18 वाचा →