भाग 1: हे कठीण का आहे (rust, 1–4) · भाग 2: प्रती (blue, 5–8) · भाग 3: एकमत (green, 9–12). प्रत्येक आकृती खऱ्या, deterministic lab मधून काढली आहे — dist/demo.py छापतो तेच आकडे — आणि प्रत्येकीखाली एक lab आहे जिथे तुम्ही स्वतः रस्ते तोडता आणि शाखा थांबवता. वर्तुळातील क्रमांक पाळा 1 → 2 → 3.
1 📨 Partial failure
निरोप्यामार्फत बोलणाऱ्या शाखा — हरवलेली चिठ्ठी, बंद पडलेली शाखा आणि हळू रस्ता इथून सगळे सारखेच दिसतात.
🧒 सोप्या शब्दांत
शाळेच्या चार शाखा आहेत: पुणे, नाशिक, नागपूर आणि कोल्हापूर. त्या एकच नोंदवही वापरतात आणि निरोप्यामार्फत बोलतात. पुणे नाशिकला 20 चिठ्ठ्या पाठवते. 18 पोहोचतात, 2 हरवतात. उत्तर आले नाही तर पुण्याला कारण कळत नाही. चिठ्ठी हरवली? नाशिक बंद आहे? की उत्तर फक्त उशिरा येत आहे?
📖 नवे शब्दdistributed system — एकच काम मिळून सांभाळणारी आणि network वरून बोलणारी अनेक machinespartial failure — एक भाग बंद पडतो पण बाकी चालू राहतो, आणि बाहेरून ते फक्त हळूपणा वाटतेmessage loss — कधीच न पोहोचणारी चिठ्ठी, जसे पुण्याच्या 20 पैकी 2 चिठ्ठ्याlatency — चिठ्ठी पोहोचायला लागणारा वेळ, जसे 5–48 ms
⏪ आधी
एका इमारतीत एक शाळा आणि एकच नोंदवही होती; office उघडे असेल तर उत्तर मिळे, नसेल तर ते बंद आहे हे कळत असे.
💡 काय
Distributed system म्हणजे शाखा: पुणे, नाशिक, नागपूर, कोल्हापूर एकच नोंदवही ठेवतात आणि निरोप्यामार्फत एकमत करतात.
⚙️ कसे
पुणे नाशिकला 20 चिठ्ठ्या पाठवते, 10% हरवतात: 20 पैकी 18 पोहोचतात 5–48 ms मध्ये, आणि 2 हरवतात, परत काहीच कळत नाही.
🎯 का
पुण्याहून पाहिले तर हरवलेली चिठ्ठी, बंद पडलेले नाशिक, हरवलेले उत्तर आणि उशिराचे उत्तर सगळे सारखेच दिसतात: हेच partial failure.
🚀 पुढे
पुढचा धडा विचारतो किती वाजले: पुणे आणि नाशिकची घड्याळे पुढे-मागे होतात, आणि wall-clock क्रम एक खरा बदल फेकून देतो.
🧪 इथे करून पाहा — पुणे निरोप्यामार्फत नाशिकला चिठ्ठ्या पाठवते — हरवणे, उशीर आणि रस्ता बदलून पाहा
प्रत्येक शाखेचे घड्याळ थोडेसे चुकीचे असते — wall time घटनांचा क्रम का ठरवू शकत नाही, आणि Lamport clocks.
🧒 सोप्या शब्दांत
पुण्याचे घड्याळ थोडे पुढे आहे आणि नाशिकचे थोडे मागे. पुणे 'exam at 10' लिहिते, मग नाशिक 'exam at 11' लिहिते. घड्याळाच्या वेळेनुसार पुणे शेवटचे दिसते, म्हणून नाशिकचा नवा बदल हरवतो. म्हणून शाखा घटना मोजतात: पुणे लिहिते 1, नाशिकला मिळते 2, नाशिक लिहिते 3.
📖 नवे शब्दclock skew — एकाच क्षणी दोन घड्याळांनी वेगवेगळी वेळ दाखवणे, जसे 140 ms चा फरकwall clock — machine वरची नेहमीची वेळ; ती पुढे-मागे होऊ शकते आणि उडी मारू शकतेLamport clock — प्रत्येक घटनेबरोबर वाढणारा counter; कारणाला नेहमी लहान क्रमांक मिळतो
⏪ आधी
शाखा प्रत्येक बदलावर आपल्या घड्याळाची वेळ टाकत आणि त्यानुसार क्रम लावत, सगळी घड्याळे सारखीच वेळ दाखवतात असे मानून.
💡 काय
घड्याळे पुढे-मागे होतात: पुणे 10:00:00.120 दाखवते तेव्हा नाशिक 09:59:59.980 दाखवते. Lamport clock त्याऐवजी घटना मोजते.
⚙️ कसे
पुणे लिहिते (L=1), नाशिकला ती मिळते (L=2), नाशिक लिहिते (L=3): कारणाला नेहमी लहान क्रमांक मिळतो.
🎯 का
Wall time नुसार क्रम लावल्याने पुण्याचे 'exam at 10' शेवटचे दिसले, आणि नाशिकचा नंतरचा 'exam at 11' बदल गुपचूप फेकला गेला.
🚀 पुढे
पुढचा धडा विचारतो आधी, नंतर की दोन्ही एकाच वेळी: vector clocks खरा क्रम आणि दोन स्वतंत्र बदल वेगळे ओळखतात.
🧪 इथे करून पाहा — Lamport clocks — घटना घडवा आणि चिठ्ठ्या पाठवा; मग भिंतीवरची घड्याळे पुढे-मागे करा आणि last-writer-wins चुकीचा विजेता निवडतो ते पाहा
आधी, नंतर, की एकाच वेळी — vector clocks खरे conflicts आणि साधा उशीर यातला फरक ओळखतात.
🧒 सोप्या शब्दांत
आता प्रत्येक चिठ्ठीवर एक छोटा तक्ता असतो: प्रत्येक शाखेचा एक आकडा. पुणे e1 लिहिते. नाशिक e1 वाचते, मग e2 लिहिते, म्हणून e1 हा e2 च्या आधी. नागपूर दोन्ही माहीत नसताना e3 लिहिते. कोणीच दुसऱ्याचे पाहिले नाही, म्हणून e3 दोघांशी concurrent आहे. हा कोणीतरी सोडवायचा खरा conflict आहे.
📖 नवे शब्दvector clock — प्रत्येक चिठ्ठीवरचा प्रत्येक शाखेचा एक counter, लिहिणाऱ्याने काय पाहिले होते ते दाखवतोhappened before — एका बदलाने दुसरा आधी पाहिला होता, जसे e2 च्या आधी e1concurrent — कोणत्याही बदलाने दुसरा पाहिला नाही, जसे e3 आणि e2conflict — दोन स्वतंत्र बदल, जे merge करावे लागतात किंवा माणसाने निवडावे लागतात
⏪ आधी
Lamport क्रमांक प्रत्येक बदल एका रांगेत लावत, पण दोन शाखांनी एकमेकांना न कळता बदल केले का हे सांगू शकत नसत.
💡 काय
Vector clock म्हणजे प्रत्येक चिठ्ठीवर प्रत्येक शाखेचा एक counter, त्यामुळे लिहिणाऱ्याने कोणते बदल वाचले होते ते नेमके दिसते.
⚙️ कसे
पुण्यात e1, e1 वाचून नाशिकमध्ये e2, काहीच माहीत नसताना नागपूरमध्ये e3: e1 हा e2 च्या आधी, आणि e3 दोघांशी concurrent.
🎯 का
Concurrent म्हणजे कोणीच दुसऱ्याचे पाहिले नाही: हा सोडवायचा खरा conflict आहे, शेवटी आला तो निवडायचा क्रम नव्हे.
🚀 पुढे
पुढचा धडा विचारतो कोल्हापूर बंद पडले की फक्त हळू आहे: heartbeats आणि timeout ठरवतात, आणि दोन्ही निवडींची किंमत असते.
🧪 इथे करून पाहा — vector clocks — घटना घडवा, चिठ्ठ्या पाठवा, मग कोणत्याही दोन घटनांची तुलना करा
बंद पडली की फक्त हळू? Heartbeats, timeouts आणि खोटे अलार्म व उशिरा कळणे यांच्यातील तडजोड.
🧒 सोप्या शब्दांत
कोल्हापूर सुमारे दर 100 ms ला 'मी चालू आहे' चिठ्ठी पाठवते. दोनदा ती उशिरा येते, 340 ms आणि 180 ms, मग कोल्हापूर खरेच थांबते. 150 ms मर्यादेने इतर शाखा 2 खोटे alarm देतात. 800 ms ने खोटा alarm नाही, पण खरे थांबणे 800 ms नंतरच लक्षात येते.
📖 नवे शब्दheartbeat — पुन्हा पुन्हा पाठवली जाणारी छोटी 'मी चालू आहे' चिठ्ठीtimeout — शाखा बंद पडली असे म्हणण्याआधी heartbeat ची किती वेळ वाट पाहायची ती वेळfalse alarm — शाखा फक्त हळू असताना ती बंद पडली असे म्हणणे, जसे 150 ms वरचे 2GC pause — program memory साफ करायला थांबतो आणि बंद पडल्यासारखा दिसतो तो क्षण
⏪ आधी
शाखा गप्प झालेल्या शाखेची कायम वाट पाहत, किंवा ती अजून चालू आहे का हे शोधायला कोणीतरी फोन फिरवत असे.
💡 काय
Failure detector heartbeats ऐकतो; timeout मध्ये एकही आला नाही तर तो ती शाखा बंद पडली असे जाहीर करतो.
⚙️ कसे
कोल्हापूरच्या gaps मध्ये 340 ms आणि 180 ms आहेत: 150 ms timeout ने 2 खोटे alarm, 800 ms ने 0, पण लक्षात यायला 800 ms.
🎯 का
जलद आणि शांत दोन्ही एकदम होता येत नाही, म्हणून timeout जुळवा आणि खोट्या alarm नंतरची प्रत्येक कृती पुन्हा करायला सुरक्षित ठेवा.
🚀 पुढे
पुढचा धडा नोंदवहीच्या प्रती ठेवतो: async replication जलद आहे पण failover वर गुण हरवतो, sync काहीच हरवत नाही.
🧪 इथे करून पाहा — कोल्हापूरच्या heartbeat मधली अंतरे — timeout हलवा आणि खोटे alarm विरुद्ध मृत्यू लक्षात यायला लागणारा वेळ मोजा
रजिस्टरच्या प्रती — leader आणि followers, synchronous विरुद्ध asynchronous, आणि failover मध्ये काय हरवू शकते.
🧒 सोप्या शब्दांत
पुण्याकडे मुख्य नोंदवही आहे आणि इतर शाखांकडे प्रती. पुणे 4 गुणांसाठी 'saved' म्हणते, मग पुणे बंद पडते. पुण्याने प्रतींची वाट पाहिली नसेल, तर नव्या प्रमुखाकडे फक्त g1 आणि g2 असतात, g3 आणि g4 गेले. प्रत्येक वेळी एका प्रतीची वाट पाहिली असेल, तर चारही वाचतात, पण प्रत्येक write हळू झाला.
📖 नवे शब्दreplica — दुसऱ्या शाखेवर ठेवलेली नोंदवहीची प्रतasynchronous — आधी 'saved' म्हणा आणि नंतर copy करा; जलद, पण failover मध्ये data हरवू शकतोsynchronous — follower कडे प्रत पोहोचल्यावरच 'saved' म्हणा; हळू, पण काहीच हरवत नाहीfailover — प्रमुख बंद पडल्यावर एक follower प्रमुख होतो
⏪ आधी
पुण्यात एकच नोंदवही: पुणे बंद पडले की प्रत्येक शाखा कालच्या रात्रीच्या backup मधून restore होईपर्यंत थांबत असे.
💡 काय
Replication नोंदवहीच्या प्रती इतर शाखांवर ठेवते; पुणे प्रमुख (leader) असते आणि followers त्याचा log copy करतात.
⚙️ कसे
4 गुण acknowledged, मग पुणे बंद पडते: async failover g1 आणि g2 ठेवतो आणि g3, g4 हरवतो; sync चारही ठेवतो.
🎯 का
Async मध्ये acknowledged data नाहीसा होऊ शकतो; sync मध्ये प्रत्येक write थांबतो. Semi-sync एक खात्रीची प्रत ठेवतो, बाकी async.
🚀 पुढे
पुढचा धडा पुरेशा प्रतींना एकमत करू देतो: N=3 मध्ये R=2 वाचणे आणि W=2 लिहिणे नेहमी सर्वात नवी version पाहते.
🧪 इथे करून पाहा — पुणे leader, नाशिक आणि नागपूर प्रती ठेवतात — गुण लिहा, काही पाठवा, मग पुणे बंद पडू द्या
N पैकी W ला लिहा, R मधून वाचा — R + W > N ला सर्वात नवीन का दिसते, आणि read repair.
🧒 सोप्या शब्दांत
नोंदवहीच्या 3 प्रती आहेत. 'exam moved to Tuesday' हा बदल फक्त 2 प्रतींपर्यंत पोहोचतो; प्रत 2 अजून Monday सांगते. वाचणारी 2 प्रतींना विचारते आणि नवी version घेते, म्हणून तिला नेहमी Tuesday दिसतो. जाता जाता ती जुनी प्रत दुरुस्त करते. दोन writes अधिक दोन reads हे तीन प्रतींपेक्षा जास्त आहे.
📖 नवे शब्दquorum — read किंवा write वर एकमत करायला पुरेशा प्रती, जसे 3 पैकी 2R + W > N — read आणि write गटांत नेहमी एक सामायिक प्रत असते, म्हणून सर्वात नवीन नेहमी दिसतेread repair — जुनी प्रत सापडलेली वाचणारी व्यक्ती ती तिथेच दुरुस्त करतेanti-entropy — कोणी न वाचणाऱ्या प्रती दुरुस्त करणारी background दुरुस्ती
⏪ आधी
प्रत्येक बदल प्रत्येक प्रतीपर्यंत पोहोचायलाच हवा होता, त्यामुळे एक हळू किंवा गैरहजर शाखा शाळेतील प्रत्येक write अडवत असे.
💡 काय
Quorum म्हणजे पुरेशा प्रतींचे एकमत: N पैकी W प्रतींवर लिहा, R वरून वाचा, आणि R + W > N ठेवा म्हणजे त्या एकमेकांवर येतात.
⚙️ कसे
'exam moved to Tuesday' 3 पैकी W=2 पर्यंत पोहोचला; R=2 read तेच परत देतो आणि अजून Monday सांगणारी जुनी प्रत 2 दुरुस्त करतो.
🎯 का
2 + 2 > 3 असल्याने प्रत्येक read quorum प्रत्येक write quorum ला भेटतो, त्यामुळे वाचणाऱ्याला सर्वात नवी version नेहमी दिसते.
🚀 पुढे
पुढचा धडा वाचणाऱ्याला काय वचन आहे त्याला नावे देतो: linearizable, sequential, causal, read-your-writes किंवा eventual.
🧪 इथे करून पाहा — N प्रती — write कोणत्या प्रतींपर्यंत पोहोचतो आणि read कोणत्या प्रतींना विचारतो ते निवडा
Linearizable, sequential, causal, read-your-writes, eventual — प्रत्येक जण वाचणाऱ्याला काय वचन देतो.
🧒 सोप्या शब्दांत
पालक विचारतात 'exam day कोणता?' उत्तर वचनावर अवलंबून असते. सर्वात मजबूत वचन एकाच प्रतीसारखे वागते: नेहमी सर्वात नवीन. कमी मजबूत: Dipika ला तिने केलेला बदल नेहमी दिसतो, इतर मागे असू शकतात. सर्वात कमकुवत: बदल थांबले की प्रती एकमत होतात. मजबूत वचनांना वेळ लागतो.
📖 नवे शब्दlinearizable — प्रत्येक read सर्वात नवा पूर्ण write पाहतो, जणू एकच प्रत आहेcausal — तुम्ही बदलाची notice पाहिली असेल तर नवा timetable ही तुम्हाला दिसेलचread-your-writes — तुमचा स्वतःचा बदल तुम्हाला नेहमी दिसतो, इतरांना तो नंतर दिसू शकतोeventual — writes थांबले की प्रती एकमत होतात; तोपर्यंत काहीही दिसू शकते
⏪ आधी
वाचणाऱ्याला काय वचन आहे हे कोणीच सांगत नसे, त्यामुळे एका पालकाला नवा exam day दिसे तर दुसऱ्याला अजून जुना.
💡 काय
Consistency model म्हणजे वाचणाऱ्याला मिळणारे वचन, linearizable (जणू एकच प्रत) पासून eventual पर्यंत.
⚙️ कसे
'Exam day कोणता?' विचारा: linearizable सर्वात नवीन दाखवतो, causal notice शिवाय नवा timetable कधीच दाखवत नाही.
🎯 का
जास्त मजबूत वचनाला coordination ची किंमत लागते, latency आणि availability मध्ये, म्हणून प्रत्येक data साठी वचन वेगळे निवडा.
🚀 पुढे
पुढचा धडा रस्ता तोडतो: CP उत्तर नाकारतो, AP जुने उत्तर देतो, आणि last-writer-wins एक खरा write टाकून देतो.
🧪 इथे करून पाहा — एक वचन आणि एक परिस्थिती निवडा — प्रत्येक वाचकाला काय दिसू शकते?
रस्ता तुटतो तेव्हा: नकार द्या किंवा जुने उत्तर द्या — आणि दोन्ही बाजूंनी केलेले दोन बदल कसे मिटवायचे.
🧒 सोप्या शब्दांत
पुणे-नाशिक आणि नागपूर-कोल्हापूर यांच्यातला रस्ता तुटला आहे. नागपूरकडे जुना exam day, v1 आहे. बरोबर राहायचे ठरवले तर ते उत्तर नाकारते. उघडे राहायचे ठरवले तर ते v1 देते, जे जुने आहे. दरम्यान दोन्ही बाजूंनी 3A trip चा दिवस लिहिला: Friday आणि Saturday. Last-writer-wins Saturday ठेवतो आणि Friday टाकून देतो.
📖 नवे शब्दpartition — शाखांमधला रस्ता तुटतो, पण दोन्ही बाजू चालूच राहतातCP — रस्ता तुटलेला असताना चुकीचे उत्तर देण्याऐवजी नकार द्याAP — रस्ता तुटलेला असताना नेहमी उत्तर द्या, ते जुने असले तरीlast-writer-wins — सर्वात नवा stamp असलेला write ठेवा आणि दुसरा गुपचूप टाकून द्याPACELC — Partition मध्ये A किंवा C निवडा; Else म्हणजे इतर वेळी Latency किंवा Consistency
⏪ आधी
शाखांमधले रस्ते कधी तुटत नाहीत असे सगळे मानत, त्यामुळे तुटलेल्या शाखेने काय करावे हे कोणी ठरवलेच नव्हते.
💡 काय
CAP: रस्ता तुटला (partition) की प्रत्येक शाखेने बरोबर राहणे (CP) किंवा उत्तर देत राहणे (AP) यापैकी एक निवडायचे.
⚙️ कसे
नागपूरकडे v1, सर्वात नवी v2: CP नकार देतो, AP जुनी v1 देतो; LWW 'Saturday' ठेवतो आणि 'Friday' टाकून देतो.
🎯 का
Partition ही निवड करायला भाग पाडतो. PACELC जोडतो की सामान्य दिवशीही latency आणि consistency यांत देवाणघेवाण असते.
🚀 पुढे
पुढचा धडा Raft ने एक प्रमुख (leader) निवडतो: 5 पैकी 3 मते जिंकतात, आणि अल्पसंख्य बाजू कधीच निवड किंवा commit करू शकत नाही.
🧪 इथे करून पाहा — रस्ता तोडा, CP किंवा AP निवडा, मग तो जोडा आणि दोन्ही बदलांचा निकाल लावा
एका leader आणि एका log वर एकमत — terms, मते, बहुमत, आणि अल्पमतातील बाजू का थांबते.
🧒 सोप्या शब्दांत
पाच शाखा, आता सातारा सोबत, एका प्रमुखासाठी मत देतात. नाशिक पाचही मते जिंकते. 5 पैकी 3 कडे बदल पोहोचला तरच तो ग्राह्य. मग रस्ता तुटतो: एका बाजूला नाशिक आणि पुणे, दुसऱ्या बाजूला नागपूर, कोल्हापूर आणि सातारा. नाशिकला फक्त 2 मते मिळतात आणि ते प्रमुख राहू शकत नाही. नागपूरला 3 मिळतात आणि ते नवे प्रमुख होते.
📖 नवे शब्दconsensus — काही बंद पडले तरी अनेक machines नी एकाच value वर एकमत करणेRaft — एक consensus पद्धत: प्रमुखासाठी मत द्या, आणि प्रमुख आपला log बाकीच्यांना copy करतोmajority — सगळ्या शाखांपैकी अर्ध्याहून जास्त, जसे 5 पैकी 3term — एक निवडणूक फेरी; प्रत्येक term मध्ये जास्तीत जास्त एकच प्रमुख
⏪ आधी
जुनी मुख्य शाखा बंद पडली की कोणीतरी हाताने नवी निवडत असे, आणि कधी कधी दोघींनाही आपणच प्रमुख वाटत असे.
💡 काय
Raft म्हणजे consensus: शाखा प्रत्येक term मध्ये एका प्रमुखाला मत देतात, आणि बहुमताने copy केल्यावरच बदल ग्राह्य धरला जातो.
⚙️ कसे
नाशिक 5/5 जिंकते; 5 पैकी 3 वर 'exam on Tuesday' commit, 2 वर 'trip on Friday' नाही. रस्ता तुटल्यावर नागपूर 3/5 जिंकते.
🎯 का
2 शाखांच्या बाजूला फक्त 2/5 मिळतात आणि ती निवड किंवा commit करू शकत नाही, त्यामुळे एका term मध्ये कधीच दोन प्रमुख नसतात.
🚀 पुढे
पुढचा धडा timetable ला कुलूप लावतो: lease संपते, आणि क्रमांक-टोकन (fencing token) थांबलेल्या holder ला लिहू देत नाही.
🧪 इथे करून पाहा — पाच शाखा Raft चालवतात — कोण पोहोचू शकते ते निवडा, निवडणुका घ्या, entries जोडा
संपणारे कुलूप, थांबलेला धारक — आणि जुन्या writes थांबवणारा token.
🧒 सोप्या शब्दांत
Katrina timetable चे कुलूप 1 second साठी घेते आणि तिला token 1 मिळतो. मग ती 2 seconds थांबून राहते. कुलूप संपते, म्हणून Aishwarya token 2 सह ते घेते आणि लिहिते. Katrina जागी होते, अजून कुलूप तिच्याकडे आहे असे तिला वाटते, आणि token 1 सह लिहिते. नोंदवहीने token 2 आधीच पाहिला आहे, म्हणून ती तिला नकार देते.
📖 नवे शब्दlock — एका वेळी फक्त एकच holder timetable बदलू शकतोlease — आपोआप संपणारे कुलूप, त्यामुळे बंद पडलेला holder कायम अडवू शकत नाहीfencing token — प्रत्येक नव्या holder सोबत वाढणारा क्रमांक; storage जुने क्रमांक नाकारते
⏪ आधी
कुलूप कधी संपतच नसे, त्यामुळे timetable चे कुलूप धरून बंद पडलेली शाखा सगळ्यांना कायमचे अडवत असे.
💡 काय
Lease म्हणजे संपणारे कुलूप; क्रमांक-टोकन (fencing token) म्हणजे कुलूपाच्या प्रत्येक नव्या holder सोबत वाढणारा क्रमांक.
⚙️ कसे
Katrina ला token 1 मिळतो आणि ती 2 s थांबते; Aishwarya ला token 2 मिळतो आणि ती लिहिते; Katrina चा उशिराचा token 1 write नाकारला जातो.
🎯 का
Token तपासला नाही तर Katrina ची 'timetable v1' नव्या कामावर लिहिली जाते; फक्त lease पुरेशी नाही.
🚀 पुढे
पुढचा धडा पुनरावृत्ती हाताळतो: रांग pay-dipika पुन्हा देते, आणि फक्त idempotent consumer एकदाच पैसे देतो.
🧪 इथे करून पाहा — fencing token सह lease — pause आणि lease बदला, token तपासणी बंद करा
At-least-once delivery अधिक idempotency — हाच 'exactly once' चा खरा अर्थ.
🧒 सोप्या शब्दांत
रांग पैसे देण्याच्या चिठ्ठ्या पाठवते: Katrina ला द्या, Dipika ला द्या, Aishwarya ला द्या. एखादी चिठ्ठी दोनदा येऊ शकते, आणि pay-dipika दोनदा येते. साधा worker Dipika ला दोनदा पैसे देतो. काळजी घेणारा worker केलेली प्रत्येक चिठ्ठी लिहून ठेवतो आणि पुन्हा आलेली सोडून देतो, म्हणून प्रत्येकाला एकदाच पैसे मिळतात.
📖 नवे शब्दat-least-once — प्रत्येक चिठ्ठी पोहोचते, पण काही दोनदा पोहोचू शकतातidempotent — दोनदा केले तरी परिणाम एकदा केल्यासारखाचidempotency key — प्रत्येक चिठ्ठीवरचे वेगळे नाव, म्हणजे पुन्हा आलेली ओळखता येतेeffectively once — at-least-once delivery अधिक idempotency: प्रत्येक परिणाम एकदाच घडतो
⏪ आधी
Teams रांग प्रत्येक message नेमका एकदाच देईल यावर विसंबत, आणि तो आधीच हाताळला आहे का ते तपासत नसत.
💡 काय
Effectively once म्हणजे at-least-once delivery अधिक idempotency: तोच message दोनदा आला तरी परिणाम एकदाच.
⚙️ कसे
रांग pay-dipika पुन्हा देते: साधा consumer Dipika ला दोनदा पैसे देतो, idempotent consumer 3 जणांना एकदाच देतो.
🎯 का
Network वर wire-level exactly once अस्तित्वातच नाही, म्हणून idempotency keys आणि dedupe tables हे काम करतात.
🚀 पुढे
पुढचा धडा 'नंतर या' म्हणतो: bounded रांग 100 requests नाकारते पण थांबणे 2.0 s ऐवजी 1.0 s वर ठेवते.
🧪 इथे करून पाहा — रांग काही संदेश पुन्हा पाठवते — consumer काम दोनदा करतो का?
लवकरच 'नंतर प्रयत्न करा' म्हणा — मर्यादित रांगा, load shedding, आणि distributed system चा संपूर्ण नकाशा.
🧒 सोप्या शब्दांत
दर सेकंदाला 120 requests येतात, पण फक्त 100 हाताळता येतात. रांगेला मर्यादा नसेल तर 10 seconds नंतर थांबणे 2.0 s होते, आणि वाढतच राहते. 200 ची मर्यादा असेल तर थांबणे 1.0 s वरच राहते, आणि 100 requests ना दारातच 'नंतर या' सांगितले जाते. खूप लांब थांबण्यापेक्षा स्पष्ट नकार बरा.
📖 नवे शब्दbackpressure — व्यस्त service मागे ढकलते आणि पाठवणाऱ्यांना हळू व्हायला सांगतेbounded queue — मर्यादा असलेली रांग, जसे 200; जास्तीच्या requests नाकारल्या जातातload shedding — बाकीचे जलद राहावे म्हणून काही काम लवकरच नाकारणे, जसे 100 नाकारल्या429 / 503 — 'खूप requests' किंवा 'नंतर या' असा अर्थ असलेली HTTP उत्तरे
⏪ आधी
प्रत्येक request स्वीकारली जात असे, त्यामुळे जास्त load वर रांग वाढत गेली आणि प्रत्येक request थांबून शेवटी time out झाली.
💡 काय
Backpressure म्हणजे bounded रांग, जी थांबणे कायम वाढू देण्याऐवजी लवकरच 'नंतर या' (429/503) सांगते.
⚙️ कसे
120/s येतात, 100/s हाताळल्या जातात: unbounded थांबणे 10 s पर्यंत 2.0 s होते; 200 ची मर्यादा 1.0 s ठेवते आणि 100 नाकारते.
🎯 का
Backoff सह स्पष्ट 'नंतर या' हे सगळ्यांसाठी हळू timeout पेक्षा चांगले, आणि load खाली memory सुरक्षित राहते.
🚀 पुढे
पुढे कुठे: System Design school हे सगळे खऱ्या designs मध्ये वापरते, Scaling traffic हाताळते, Database आणखी खोलात जाते.
🧪 इथे करून पाहा — सेवा देता येईल त्यापेक्षा जास्त येते — रांग वाढू द्या, किंवा मर्यादेवर "नंतर प्रयत्न करा" सांगा