3.0 भाग 3 का परिचय: सिस्टम

आर्किटेक्चर उन निर्णयों का समुच्चय है जिन्हें पलटना महंगा होता है। आप किसी सिस्टम को हिस्सों में कैसे विभाजित करते हैं? वे हिस्से आपस में कैसे संवाद करते हैं? डेटा को किस तरह मॉडल किया जाता है? और पूरा सिस्टम लोड और विफलता के अंतर्गत कैसा व्यवहार करता है? भाग 3 इन निर्णयों को सोच-समझकर लेने के बारे में है। एक छोटी टीम में, आर्किटेक्चर कुछ लोगों के दिमाग में रह सकता है और काम करते-करते विकसित हो सकता है। एक बड़े संगठन में (सैकड़ों इंजीनियर, दर्जनों टीमें, ऐसे सिस्टम जो उन्हें बनाने वाले लोगों के करियर से भी अधिक समय तक चलेंगे), आर्किटेक्चर वह चीज़ बन जाता है जो सभी को समन्वित रखता है। जब यह स्पष्ट होता है, तो टीमें बिना टकराए स्वतंत्र रूप से आगे बढ़ती हैं। जब यह अस्पष्ट होता है, तो हर क्रॉस-टीम निर्भरता एक बातचीत बन जाती है, और हर घटना एक पुरातत्व परियोजना बन जाती है।

दांव सबसे अधिक एंटरप्राइज़ और सरकार में होते हैं। एक टैक्स इंजन, एक लाभ (बेनिफ़िट्स) प्लेटफ़ॉर्म, एक राष्ट्रीय स्वास्थ्य रिकॉर्ड, या किसी बैंक की कोर लेजर लंबे समय तक चलने वाली, भारी विनियमित, विभागों के बीच साझा की जाने वाली, और जनता के प्रति जवाबदेह होती है। कपलिंग, डेटा स्वामित्व, और गुणवत्ता विशेषताओं के बारे में आज आप जो निर्णय लेते हैं, वे एक दशक या उससे अधिक समय तक क्या संभव है इसे सीमित कर देंगे। नियामक और लेखा परीक्षक (ऑडिटर) तेज़ी से दस्तावेज़ीकृत, बचाव-योग्य आर्किटेक्चर की अपेक्षा कर रहे हैं, जिसमें वास्तविक प्रमाण हो कि विश्वसनीयता, सुरक्षा, गोपनीयता, और स्थायित्व को शुरू से डिज़ाइन किया गया था, बाद में जोड़ा नहीं गया। जो विफलताएँ सुर्खियाँ बनती हैं वे आर्किटेक्चरल विफलताएँ होती हैं: पोर्टल जो लॉन्च के दिन ढह जाते हैं, फाइलिंग सिस्टम जो समय सीमा पर टाइम-आउट हो जाते हैं, माइग्रेशन जो रिकॉर्ड खो देते हैं या दोगुना गिन लेते हैं।

यह भाग स्थायी बुनियादी सिद्धांतों से शुरू होता है, फिर ठोस संरचनात्मक विकल्पों से होकर गुजरता है, उसके बाद वितरण, डेटा, और स्केल की वास्तविकताओं में प्रवेश करता है, और उस सबसे कठिन समस्या के साथ समाप्त होता है जिसका अधिकांश बड़े संगठनों को वास्तव में सामना करना पड़ता है: वे सिस्टम जिन्हें वे पहले से चला रहे हैं उनका आधुनिकीकरण करना। जो चीज़ इसे एक साथ बांधती है वह यह है: अच्छा आर्किटेक्चर सचेत ट्रेड-ऑफ़ की एक शृंखला है, न कि कोई फैशनेबल डिफ़ॉल्ट।

इस भाग के अध्याय

• 3.1 आर्किटेक्चर के बुनियादी सिद्धांत। वे स्थायी उपकरण जो तकनीकी फैशन से आगे तक टिके रहते हैं: गुणवत्ता विशेषताएँ (“-ilities”), आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताएँ, फ़िटनेस फ़ंक्शन (स्वचालित परीक्षण जो किसी चुनी गई आर्किटेक्चरल गुणवत्ता की रक्षा करते हैं) और इवोल्यूशनरी आर्किटेक्चर, C4 model (चार ज़ूम स्तरों पर नेस्टेड आर्किटेक्चर डायग्राम) और arc42 (एक आर्किटेक्चर दस्तावेज़ीकरण टेम्पलेट) के साथ हल्का दस्तावेज़ीकरण, और संरचित ट्रेड-ऑफ़ विश्लेषण।

• 3.2 आर्किटेक्चरल शैलियाँ और पैटर्न। प्रमुख सिस्टम आकारों का एक सर्वेक्षण, मोनोलिथ से लेकर microservices, CQRS (Command Query Responsibility Segregation, जो रीड मॉडल को राइट मॉडल से अलग करता है) और इवेंट सोर्सिंग (स्टेट को एपेंड-ओनली इवेंट लॉग के रूप में संग्रहीत करना) के साथ event-driven architectures, गेटवे के साथ service mesh (सर्विस-टू-सर्विस संचार के लिए एक समर्पित इन्फ्रास्ट्रक्चर परत), serverless, और hexagonal तथा क्लीन आर्किटेक्चर तक, साथ ही यह मार्गदर्शन कि कौन-सी शैली कब उपयुक्त है, यह सब Conway’s Law (सिस्टम प्रायः उस संगठन की संचार संरचना को प्रतिबिंबित करते हैं जो उन्हें बनाता है) के ढांचे में प्रस्तुत किया गया है।

• 3.3 वितरित सिस्टम। वे कठोर सच्चाइयाँ जो नेटवर्क सीमा पार करते ही सामने आती हैं (अविश्वसनीय नेटवर्क, आंशिक विफलता, कोई साझा घड़ी नहीं), और मानक बचाव उपाय: कंसिस्टेंसी तर्क, idempotency (किसी ऑपरेशन को दोहराने के लिए सुरक्षित बनाना), बैकऑफ़ के साथ रीट्राई, circuit breakers (जो किसी विफल निर्भरता को कॉल करना बंद कर देते हैं), sagas (क्षतिपूरक अनडू चरणों के साथ स्थानीय लेन-देन की शृंखलाएँ), और वितरित ऑब्ज़र्वेबिलिटी।

• 3.4 डेटा आर्किटेक्चर और स्टोरेज। डेटा को स्केल पर किस तरह मॉडल किया जाता है, संग्रहीत किया जाता है, संगत रखा जाता है, और तेज़ी से प्रदान किया जाता है: प्रमुख स्टोरेज पैराडाइम और प्रत्येक का उपयोग कब करें, polyglot persistence (एक ही सिस्टम में कई विशेषीकृत डेटा स्टोर का उपयोग करना), स्कीमा इवोल्यूशन और माइग्रेशन, कैशिंग और CDNs (कंटेंट डिलीवरी नेटवर्क), और लोड के अंतर्गत लेन-देन तथा समवर्तीता (कॉन्करेंसी)।

• 3.5 स्केलेबिलिटी, प्रदर्शन, और रेज़िलिएंस। तीन अलग-अलग गुण जिन्हें शुरू से डिज़ाइन किया जाना चाहिए, बाद में जोड़ा नहीं जाना चाहिए: हॉरिज़ॉन्टल और वर्टिकल स्केलिंग, स्टेटलेसनेस और sharding (किसी की के आधार पर डेटा को मशीनों में विभाजित करना), लोड बैलेंसिंग और ऑटोस्केलिंग, प्रदर्शन बजट, रेज़िलिएंस पैटर्न और chaos engineering, और RTO (recovery time objective) तथा RPO (recovery point objective) द्वारा परिभाषित मल्टी-रीजन disaster recovery।

• 3.6 लीगेसी आधुनिकीकरण। वे क्रमिक (इंक्रीमेंटल) पैटर्न जो वास्तव में काम करते हैं: स्ट्रैंगलर फ़िग (पुराने सिस्टम के चारों ओर एक नया सिस्टम बढ़ाना जब तक पुराने को रिटायर न किया जा सके) और ब्रांच-बाय-एब्स्ट्रैक्शन (डेवलपमेंट की मुख्य लाइन पर किसी इंटरफ़ेस के पीछे किसी घटक को बदलना), साथ ही लीगेसी जोखिम मूल्यांकन, mainframe और COBOL (Common Business-Oriented Language) की देखभाल (स्टीवर्डशिप), डेटा माइग्रेशन और ड्यूल-रनिंग, और उस बड़े-रीराइट के प्रलोभन का प्रतिरोध कैसे करें जो इस क्षेत्र की सबसे महंगी विफलताएँ पैदा करता है।

• 3.7 सॉफ़्टवेयर रखरखाव। सॉफ़्टवेयर जीवनकाल का प्रमुख चरण: सुधारात्मक (करेक्टिव), अनुकूली (एडैप्टिव), परिष्करणीय (परफ़ेक्टिव), और निवारक (प्रिवेंटिव) रखरखाव, प्रोग्राम कॉम्प्रिहेंशन और रीइंजीनियरिंग, और मेंटेनेबिलिटी के लिए डिज़ाइन करना ताकि लंबे समय तक चलने वाले सिस्टम में बदलाव करना किफ़ायती बना रहे।

• 3.8 इंटरऑपरेबिलिटी और ओपन स्टैंडर्ड। बेस्पोक इंटीग्रेशन के बजाय ओपन स्टैंडर्ड के माध्यम से इंटरऑपरेट करने के लिए सिस्टम डिज़ाइन करना: तकनीकी, सिंटैक्टिक, और सिमेंटिक interoperability, स्वास्थ्य सेवा में FHIR जैसे डोमेन मानक, और प्रोप्राइटरी लॉक-इन की लागत।

• 3.9 सिस्टम्स इंजीनियरिंग। जटिल सिस्टमों की एंड-टू-एंड इंजीनियरिंग, जिसमें प्रायः सॉफ़्टवेयर, हार्डवेयर, लोग, और प्रक्रियाएँ शामिल होती हैं: जीवनचक्र, आवश्यकताओं का आवंटन और ट्रेसेबिलिटी, इंटरफ़ेस, इंटीग्रेशन, तथा सत्यापन और वैलिडेशन।

• 3.10 एम्बेडेड और रियल-टाइम सिस्टम। कड़ी सीमाओं के अंतर्गत डिवाइसों के लिए सॉफ़्टवेयर: रियल-टाइम व्यवहार और डिटरमिनिज़्म, एक RTOS या बेयर-मेटल फ़र्मवेयर, सीमित मेमोरी और पावर, हार्डवेयर इंटरैक्शन, और सुरक्षा-गंभीर (सेफ़्टी-क्रिटिकल) मानक।

• 3.11 क्लाउड आर्किटेक्चर। किसी डेटा सेंटर को लिफ़्ट-एंड-शिफ़्ट करने के बजाय क्लाउड के लिए डिज़ाइन करना: सर्विस मॉडल और सर्वरलेस, फ़ेल्यर डोमेन के रूप में रीजन और अवेलेबिलिटी ज़ोन, शेयर्ड रिस्पॉन्सिबिलिटी मॉडल, मैनेज्ड-सर्विस और लॉक-इन के ट्रेड-ऑफ़, मल्टी-क्लाउड और हाइब्रिड जब वे अपनी जटिलता को सही ठहराते हैं, और लागत-सजग, वेल-आर्किटेक्टेड डिज़ाइन।

• 3.12 इवेंट-ड्रिवेन आर्किटेक्चर और मैसेजिंग। ऐसे सिस्टम बनाना जो इवेंट उत्पन्न करके और उन पर प्रतिक्रिया देकर संवाद करते हैं: क्यू बनाम ड्यूरेबल स्ट्रीम, कोरियोग्राफ़ी बनाम ऑर्केस्ट्रेशन, इवेंट सोर्सिंग और CQRS जहाँ वे उपयुक्त हों, वितरित लेन-देन के लिए सागा, डिलीवरी गारंटी और इडेम्पोटेंस, और वे पैटर्न जो असिंक्रोनस प्रवाह को विश्वसनीय बनाए रखते हैं।

• 3.13 नेटवर्किंग और कनेक्टिविटी। वह नेटवर्किंग जिससे एक एप्लिकेशन इंजीनियर वास्तव में निपटता है: DNS, TCP और HTTP का विकास, TLS टर्मिनेशन, लोड बैलेंसिंग और रिवर्स प्रॉक्सी, कंटेंट डिलीवरी और एज, सर्विस डिस्कवरी और सर्विस मेश, और वे टाइमआउट, रीट्राई, और सर्किट ब्रेकर जो नेटवर्क की अविश्वसनीयता को सहनीय बनाते हैं।

• 3.14 मल्टी-टेनेंसी और SaaS आर्किटेक्चर। एक ही सॉफ़्टवेयर इंस्टेंस से कई ग्राहकों को सेवा देना, बिना उन्हें एक-दूसरे को देखने या एक-दूसरे के संसाधन छीनने देने के: आइसोलेशन-बनाम-एफ़िशिएंसी स्पेक्ट्रम, डेटा पार्टिशनिंग, नॉइज़ी नेबर के विरुद्ध प्रति-टेनेंट कोटा, टेनेंट जीवनचक्र, और लागत आवंटन।

• 3.15 कैशिंग और सामग्री वितरण। कैश पदानुक्रम (क्लाइंट, एज और CDN, रिवर्स प्रॉक्सी, एप्लिकेशन, और डेटा स्टोर) में थोड़ी स्टेलनेस के बदले लेटेंसी, लोड, और लागत में बड़ा लाभ प्राप्त करना, साथ ही कैश इनवैलिडेशन और स्टैम्पीड सुरक्षा को प्रथम-श्रेणी डिज़ाइन के रूप में मानना।

• 3.16 API गेटवे और सर्विस मेश। API गेटवे पर नॉर्थ-साउथ ट्रैफ़िक को संभालना (राउटिंग, प्रामाणीकरण, रेट लिमिटिंग, कंपोज़िशन) और सर्विस मेश के माध्यम से ईस्ट-वेस्ट ट्रैफ़िक (म्यूचुअल TLS, ट्रैफ़िक शिफ़्टिंग, रीट्राई, ऑब्ज़र्वेबिलिटी), और यह तय करना कि मेश कब अपनी जटिलता को सही ठहराता है।

• 3.17 खोज और सूचना पुनर्प्राप्ति। सर्च को एक प्रथम-श्रेणी सिस्टम के रूप में मानना, इनवर्टेड इंडेक्स और रेलिवेंस रैंकिंग से लेकर क्वेरी समझ, फ़ेसेटिंग, और वेक्टर तथा हाइब्रिड रिट्रीवल तक, अनुमान लगाने के बजाय वास्तविक रेलिवेंस मूल्यांकन के साथ।

ये अध्याय आपस में कैसे संबंधित हैं

अध्याय क्रमशः एक-दूसरे पर आधारित हैं। अध्याय 3.1 वह शब्दावली (गुणवत्ता विशेषताएँ और ट्रेड-ऑफ़ विश्लेषण) प्रदान करता है जिसका उपयोग बाद का हर अध्याय करता है; इसमें नामित “-ilities” ठीक वही हैं जिन्हें अध्याय 3.4 और 3.5 ठोस रूप देते हैं। अध्याय 3.2 इन बुनियादी सिद्धांतों को संरचनात्मक विकल्पों में बदल देता है, और यह जिन अधिक वितरित शैलियों (माइक्रोसर्विसेज़, इवेंट-ड्रिवेन, सर्विस मेश) का समर्थन करता है वे वे लागतें लाती हैं जिन्हें प्रबंधित करना अध्याय 3.3 सिखाता है। अध्याय 3.3, 3.4, और 3.5 एक-दूसरे पर भारी रूप से निर्भर हैं: वितरण डेटा आर्किटेक्चर के कंसिस्टेंसी और स्थायित्व संबंधी निर्णयों को बाध्य करता है, और वितरण तथा डेटा मिलकर यह तय करते हैं कि आप वास्तव में किस स्तर की स्केलेबिलिटी और रेज़िलिएंस प्राप्त कर सकते हैं। अध्याय 3.6 इस चक्र को पूरा करता है, क्योंकि अधिकांश बड़े संगठन किसी खाली पृष्ठ पर निर्माण नहीं कर रहे होते: वे उन सिस्टम्स ऑफ़ रिकॉर्ड को विकसित कर रहे होते हैं जो पहले के अध्यायों में वर्णित हर विकल्प को सीमित करते हैं।

भाग 3 बाहर की ओर भी विस्तारित होता है। अध्याय 3.2 अच्छे सर्विस बाउंड्री खोजने के लिए अध्याय 2.2 के डिज़ाइन सिद्धांतों और डोमेन-ड्रिवेन डिज़ाइन का सहारा लेता है। वे परिचालन अनुशासन जो इन सिस्टमों को चालू रखते हैं भाग 9 में मिलते हैं: साइट रिलायबिलिटी इंजीनियरिंग (अध्याय 9.1) और ऑब्ज़र्वेबिलिटी (अध्याय 9.2) वे स्थान हैं जहाँ आर्किटेक्चरल रेज़िलिएंस को प्रोडक्शन में सिद्ध किया जाता है। नियामकों द्वारा मांगे गए सुरक्षा और गोपनीयता गुणों को यहाँ डिज़ाइन किया जाता है लेकिन भाग 4 में विस्तार से बताया गया है, और भाग 8 में प्लेटफ़ॉर्म और डिलीवरी प्रथाएँ यह तय करती हैं कि किसी आर्किटेक्चर को वास्तव में कई टीमों द्वारा एक साथ शिप और संचालित किया जा सकता है या नहीं।