नोड्स, एजेस, दिशाएँ
ग्राफ पर एक अनुरोध के रूप में एक वॉक
हर घटक जिससे एक अनुरोध संपर्क करता है, एक नोड है: क्लाइंट, DNS रिज़ॉल्वर, CDN एज, रिवर्स प्रॉक्सी, बैकएंड रिप्लिका, डेटाबेस, कैश।
दो नोड्स के बीच हर कनेक्शन एक निर्देशित एज है: अनुरोध आगे की ओर बहते हैं, और प्रतिक्रियाएँ वापस बहती हैं। आगे की एज एक खुली TCP कनेक्शन और उसके ऊपर प्रोटोकॉल का प्रतिनिधित्व करती है।
एकल अनुरोध इस ग्राफ के माध्यम से एक पथ है। अनुरोध का उत्तर देने के लिए सिस्टम द्वारा किया गया कुल कार्य प्रत्येक नोड पर किए गए कार्य के योग और प्रत्येक एज की लेटेंसी के योग के बराबर होता है।
इसका महत्व क्यों है? एक बार जब आप ग्राफ बना लेते हैं, तो ऐसे गुण प्रकट होते हैं जो कोड में अदृश्य होते हैं:
- हॉप काउंट (Hop count): पथ में किनारों (edges) की संख्या। प्रत्येक हॉप लेटेंसी (network round trip + node processing) जोड़ता है। कम हॉप्स = लेटेंसी का निचला स्तर (lower floor) कम।
- इन-डिग्री (In-degree): किनारे (edges) किसी नोड में कितने अंदर की ओर इशारा करते हैं। उच्च इन-डिग्री का अर्थ है कि नोड कई स्रोतों से अनुरोध प्राप्त करता है और स्वयं को स्केल या सुरक्षित करने के लिए बाध्य है।
- आउट-डिग्री (Out-degree): किनारे (edges) किसी नोड से कितने बाहर की ओर इशारा करते हैं। उच्च आउट-डिग्री का अर्थ है कि नोड कई डाउनस्ट्रीम पर निर्भर करता है और विफल होने के कई तरीके रखता है।
- कट वर्टेक्स (Cut vertex): एक अकेला नोड जिसके हटाने से ग्राफ अलग हो जाता है। बिना किसी पीयर के रिवर्स प्रॉक्सी एक कट वर्टेक्स है; इसे हटाने से उसके ओरिजिन तक सभी एक्सेस समाप्त हो जाती है।
जहाँ ट्रैफिक केंद्रित होता है
फैन-इन = केंद्रण
नोड की इन-डिग्री = उसमें इशारा करने वाले एज की संख्या। एक रिक्वेस्ट ग्राफ में, इन-डिग्री = उन अपस्ट्रीम स्रोतों की संख्या जो रिक्वेस्ट भेजते हैं।
Fan-in पैटर्न: कई क्लाइंट -> एक CDN; कई CDN एज -> कुछ मूल प्रॉक्सी; कई प्रॉक्सी -> कम बैकएंड रिप्लिका; कई बैकएंड -> एकल डेटाबेस।
संघनन महत्वपूर्ण है क्योंकि सबसे उच्च इन-डिग्री वाला नोड सबसे अधिक समग्र लोड देखता है। श्रृंखला के अंत में डेटाबेस पूरे सिस्टम में हर सक्रिय अनुरोध से क्वेरी देख सकता है, भले ही कोई भी एकल उपयोगकर्ता बहुत कुछ उत्पन्न न करे।
Fan-Out = निर्भरता
एक नोड का आउट-डिग्री = उससे बाहर की ओर इशारा करने वाली किनारों (edges) की संख्या। उच्च आउट-डिग्री का अर्थ है कई डाउनस्ट्रीम निर्भरताएं।
एक बैकएंड जो एक डेटाबेस, दो कैश, तीन बाहरी API, और एक क्यू को कॉल करता है, उसका आउट-डिग्री 7 है। इसकी सफलता की संभावना लगभग प्रत्येक डाउनस्ट्रीम की सफलता की संभावना का गुणनफल है (यदि सफल प्रतिक्रिया के लिए सभी आवश्यक हैं)।
0.999 ^ 7 ≈ 0.993: 7 डाउनस्ट्रीम वाले एक बैकएंड, जिनमें से प्रत्येक 99.9% विश्वसनीयता पर है, स्वयं के कोई भी बग होने के बावजूद, केवल ~99.3% विश्वसनीयता प्राप्त कर सकता है।
आउट-डिग्री को कम करने के लिए: डाउनस्ट्रीम परिणामों को कैश करना, गैर-महत्वपूर्ण डाउनस्ट्रीम को वैकल्पिक बनाना (graceful degradation), और जो समानांतर हो सकता है उसे समानांतर करना।
असममितता
फैन-इन (fan-in) लोड को केंद्रित करता है; फैन-आउट (fan-out) जोखिम को गुणा करता है। एक अच्छे रूप से बनाया गया ग्राफ (graph) उच्चतम प्रभाव वाले नोड्स (nodes) पर दोनों को न्यूनतम करता है।
डेटाबेस (उच्चतम फैन-इन): लोड को कम करने के लिए आक्रामक रूप से कैश करें (cache aggressively)। फैन-इन को कई नोड्स में फैलाने के लिए रीड रिप्लिका (read replicas) का उपयोग करें।
ऑर्केस्ट्रेटर सेवा (उच्चतम फैन-आउट): प्रति निर्भरता (per dependency) सर्किट ब्रेकर, ग्रेसफुल डिग्रेडेशन (graceful degradation), और बल्कहेड्स (bulkheads)।
एक सम्मिलित नोड लचीलापन खरीदता है
Indirection = एक मध्यवर्ती नोड जोड़ना
प्रॉक्सी के बिना, ग्राफ है: client -> backend। क्लाइंट को बैकएंड के पता के बारे में पता होना चाहिए। बैकएंड को हटाने के लिए क्लाइंट को अपडेट करना आवश्यक है (DNS या कॉन्फ़िगरेशन के माध्यम से)। यह एक कसकर बंधा हुआ (tight binding) संबंध है।
प्रॉक्सी के साथ, ग्राफ बन जाता है: client -> proxy -> backend। क्लाइंट केवल प्रॉक्सी के बारे में जानता है। बैकएंड को हटाने के लिए क्लाइंट को नहीं, बल्कि प्रॉक्सी के अपस्ट्रीम कॉन्फ़िगरेशन को अपडेट करना आवश्यक है।
ग्राफ ऑपरेशन: एक मौजूदा किनारे (edge) के साथ एक नोड को सम्मिलित करना। नया किनारा client -> proxy स्थिर है; नया किनारा proxy -> backend अब टीम के प्रबंधन के अधीन है।
ज्यामितीय पठन: indirection एक परत जोड़ता है जो अपस्ट्रीम परिवर्तन को डाउनस्ट्रीम परिवर्तन से अलग करता है। प्रत्येक परत के किनारे स्वतंत्र रूप से पुनः तारों (rewire) किए जा सकते हैं।
अप्रत्यक्षता (Indirection) की लागत
हर परत (layer) ये जोड़ती है:
- एक होप की विलंबता (क्लाइंट से प्रॉक्सी तक की किनारा)
- पथ पर एक और कट वर्टेक्स (प्रॉक्सी स्वयं)
- एक और जगह जहाँ गलत कॉन्फ़िगरेशन हो सकता है
लाभ (रीवायर, स्केल, शील्ड, TLS समाप्ति, लोड वितरण) आमतौर पर किसी भी गैर-सरल (non-trivial) सिस्टम के लिए लागत से अधिक होते हैं। लेकिन एक सीमा है: हर अप्रत्यक्षता की परत एक और होप और एक और SPOF (Single Point of Failure) उम्मीदवार जोड़ती है।
लोकप्रिय नियम: कोई भी समस्या अप्रत्यक्षता की एक परत जोड़कर हल की जा सकती है (अप्रत्यक्षता की बहुत सारी परतों की समस्या को छोड़कर)।
एक आर्किटेक्चर को ग्राफ के रूप में पढ़ें
संश्लेषण
अब आप एक सिस्टम आर्किटेक्चर को एक ग्राफ़ के रूप में पढ़ सकते हैं: हॉप्स की गिनती करें, कट वर्टेक्स की पहचान करें, फैन-इन केंद्रितता का मापन करें, फैन-आउट से उपलब्धता सीमा (availability ceilings) की गणना करें, और अप्रत्यक्षता (indirection) के व्यापार-बदलावों (trade-offs) का मूल्यांकन करें।
सभी चारों का प्रयोग करें।
एक नए सेवा (service) की यह आर्किटेक्चर है: clients -> CDN -> reverse proxy (2 replicas) -> backend tier (8 replicas) -> { DB primary, cache cluster (3 nodes), external API }।
सहयोगी नोट्स
सहयोगी नोट्स
यह ज्यामिति-आधारित पाठ Proxies & Origins मुख्य पाठ को एक निर्देशित ग्राफ विश्लेषण के रूप में पुनर्निर्मित करता है।
इस पाठक्रम का अगला सहयोगी, geometry_of_stateless_horizontal_scaling, मुख्य स्केलिंग पाठ से रिप्लिका गणित (replica-math) को लेता है और ज्यामितीय रूप से क्यूइंग वक्र (queueing curve), लिटल का नियम (Little's Law), और 80% उपयोगिता घुटना (utilization knee) व्युत्पन्न करता है।
बहुत अच्छा किया।