3.2 आर्किटेक्चरल शैलियाँ और पैटर्न

अवलोकन और प्रेरणा

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

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

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

यह भी देखें: अध्याय 2.2 (सॉफ़्टवेयर डिज़ाइन सिद्धांत, डोमेन-ड्रिवन डिज़ाइन सहित), अध्याय 3.1 (आर्किटेक्चर की बुनियादी बातें), और अध्याय 3.3 (वितरित सिस्टम)।

मुख्य सिद्धांत

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

सिफ़ारिशें

डिफ़ॉल्ट रूप से एक मॉड्यूलर मोनोलिथ अपनाएँ; सबूत के साथ विभाजित करें

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

जानें कि माइक्रोसर्विसेज़ कब अपनी कीमत वसूल करती हैं

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

जहाँ डीकपलिंग और असिंक्रोनी भुगतान करे वहाँ इवेंट-संचालित आर्किटेक्चर का उपयोग करें

इवेंट-संचालित आर्किटेक्चर उत्पादकों को यह जाने बिना तथ्य उत्सर्जित करने देता है कि उन्हें कौन उपभोग करता है। इससे आपको ढीली कपलिंग, लोड स्पाइक के लिए एक बफ़र, और नए उपभोक्ता जोड़ने का एक आसान तरीका मिलता है। इसका उपयोग वहाँ करें जहाँ वर्कफ़्लो स्वाभाविक रूप से असिंक्रोनस और रिएक्टिव हैं। CQRS (Command Query Responsibility Segregation) राइट मॉडल को एक या अधिक रीड मॉडलों से अलग करता है, जो तब मदद करता है जब रीड और राइट लोड या आकार तेज़ी से भिन्न होते हैं। इवेंट सोर्सिंग स्थिति को वर्तमान स्थिति के बजाय इवेंट्स के एक अपेंड-ओनली लॉग के रूप में संग्रहीत करता है, जो आपको एक परफ़ेक्ट ऑडिट ट्रेल और टाइम-ट्रैवल देता है। यह वित्त और सरकार के लिए शक्तिशाली है, जहाँ “हम इस मूल्य तक कैसे पहुँचे?” एक कानूनी प्रश्न है, लेकिन यह इवेंट्स के वर्ज़निंग, प्रोजेक्शन को फिर से बनाने, और अंततः स्थिरता के बारे में तर्क करने में वास्तविक जटिलता जोड़ता है। इन्हें जानबूझकर अपनाएँ, डिफ़ॉल्ट रूप से नहीं।

कई सेवाओं को प्रबंधित करने के लिए गेटवे, BFF, और मेश पैटर्न लागू करें

एक API गेटवे बाहरी क्लाइंट को एक ही प्रवेश बिंदु देता है, जो प्रमाणीकरण, दर सीमन, रूटिंग, और TLS (Transport Layer Security) समाप्ति को संभालता है। एक बैकएंड-फ़ॉर-फ्रंटएंड (BFF) प्रत्येक क्लाइंट प्रकार (वेब, मोबाइल, भागीदार API) को उसकी अपनी तैयार-की-गई एग्रीगेशन परत देता है, ताकि आप एक फूला हुआ एक-आकार-सबको-फिट वाला API टालें। एक सर्विस मेश क्रॉस-कटिंग चिंताओं (म्यूचुअल TLS, रीट्राई, टाइमआउट, ट्रैफ़िक शिफ्टिंग, और टेलीमेट्री) को एक साइडकार इन्फ्रास्ट्रक्चर परत में ले जाता है, ताकि एप्लिकेशन टीमों को इन्हें फिर से लागू न करना पड़े। मेश तभी जोड़ें जब सेवाओं की संख्या इन चिंताओं को प्रति-सेवा संभालना अप्रबंधनीय बना दे। कुछ सेवाओं के लिए, एक मेश उसके लायक से अधिक परिचालन भार है।

सर्वरलेस को ईमानदारी से तौलें

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

हर सेवा के अंदर व्यावसायिक लॉजिक को साफ़ रखें

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

समझौते: फ़ायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. अगली सेवा को विभाजित करने से पहले, क्या आप उस टीम को विभाजित करेंगे जो इसकी मालिक है, और इसे करने का अधिकार किसके पास है? कॉनवे के नियम का मतलब है कि एक सेवा सीमा वास्तव में एक टीम सीमा है, इसलिए एक ऐसा विभाजन जिसे संगठन चार्ट समर्थन नहीं देता, एक वितरित मोनोलिथ पैदा करता है: दो परिनियोज्य इकाइयाँ, एक रिलीज़ ट्रेन, साझा ऑन-कॉल। एक बड़े एंटरप्राइज़ में, टीमों को फिर से आकार देने का अधिकार आमतौर पर इंजीनियरिंग से ऊपर बैठता है, रिपोर्टिंग लाइनों, वित्त, और HR के साथ, यही कारण है कि आर्किटेक्चर और संगठन डिज़ाइन को एक साथ तय करना होता है। चर्चा में सबूत लाएँ: क्या प्रस्तावित सेवा के पास एक टीम है जो इसे शुरू से अंत तक अपनी बना सकती है, अपना ऑन-कॉल स्टाफ़ कर सकती है, और अपनी गति से परिनियोजित कर सकती है? यदि उत्तर नहीं है, तो या तो टीम को वित्तपोषित करें या क्षमता को मोनोलिथ में एक मॉड्यूल के रूप में रखें। स्वामित्व को विभाजित किए बिना कोड को विभाजित करना वितरण की हर लागत ख़रीदता है और स्वतंत्रता में से कुछ भी नहीं।

2. क्या आप आज अपनी प्रत्येक सेवा को स्वतंत्र रूप से परिनियोजित कर सकते हैं, या वे गुप्त रूप से लॉकस्टेप में शिप होती हैं? वितरित मोनोलिथ इस अध्याय का सबसे बुरा परिणाम है: आप सेवाओं के बीच नेटवर्क कॉल, आंशिक विफलता, और डेटा स्थिरता के लिए भुगतान करते हैं, फिर भी दूसरों के बिना एक को रिलीज़ नहीं कर सकते। बता देने वाले संकेत हैं एक साझा डेटाबेस, एक साझा लाइब्रेरी जो समन्वित अपग्रेड को मजबूर करती है, और इंटीग्रेशन टेस्ट जिन्हें पूरी संपत्ति को एक साथ चलाना पड़ता है। एक बड़ी टीम के लिए यह चुपचाप थ्रूपुट को सीमित करता है, क्योंकि हर टीम एक रिलीज़ के पीछे कतार में लग जाती है भले ही आरेख स्वतंत्रता दिखाता हो। एक हालिया बदलाव लें और गिनें कि इसे सुरक्षित बनाने के लिए कितनी सेवाओं को साथ परिनियोजित होना पड़ा; यदि यह संख्या एक ऐसे बदलाव के लिए एक से अधिक है जिसने एक ही क्षमता को छुआ, तो आपकी सीमाएँ ग़लत हैं। समाधान आमतौर पर प्रत्येक सेवा को अपना डेटा और एक स्थिर, वर्ज़न-युक्त अनुबंध देना है, अधिक सेवाएँ जोड़ना नहीं।

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

4. क्या आपका प्लेटफ़ॉर्म और ऑन-कॉल परिपक्वता वास्तव में उस शैली का समर्थन करती है जिसका आप प्रस्ताव कर रहे हैं, और क्या आप प्रतिबद्ध होने से पहले विशिष्ट अंतरालों का नाम बता सकते हैं? माइक्रोसर्विसेज़, मेश, और इवेंट-संचालित बैकबोन अपने लाभ केवल परिपक्व CI/CD, वितरित ट्रेसिंग, सर्विस डिस्कवरी, और एक ऐसी ऑन-कॉल संस्कृति के ऊपर देते हैं जो आंशिक विफलता के बारे में तर्क कर सके। एक बड़ा संगठन एक आर्किटेक्चर मंच में लक्ष्य शैली तय करने और बाद में गायब प्लेटफ़ॉर्म की खोज करने की प्रवृत्ति रखता है, एक बार जब दर्जनों सेवाएँ पहले से उत्पादन में हों और हर घटना का निदान करने में घंटों लगें। स्वतंत्र परिनियोजन और स्केलिंग के आकर्षण को इस गंभीर प्रश्न के मुकाबले तौलें कि रात 3 बजे इसे कौन चलाएगा: वही विभाजन जो टीमों को समानांतर में शिप करने के लिए मुक्त करता है, विफलता मोड को भी गुणा करता है जिन्हें प्रत्येक टीम को समझना होगा। चर्चा में एक ईमानदार सूची लाएँ: वर्तमान परिनियोजन आवृत्ति, पुनर्प्राप्ति का औसत समय, क्या आपके पास सेवा सीमाओं में ट्रेसिंग है, और एक टीम वास्तविक रूप से कितनी सेवाओं का संचालन कर सकती है। एंटरप्राइज़ और सरकारी परिवेश में, उन प्लेटफ़ॉर्म क्षमताओं के लिए खरीद और भर्ती के समय जोड़ें जिनकी आपके पास कमी है, क्योंकि एक ऐसी शैली जो एक मेश और एक प्लेटफ़ॉर्म टीम मान लेती है जिसे आपने वित्तपोषित नहीं किया है, वह एक असमर्थनीय संपत्ति चलाने की योजना है।

5. डोमेन के किन हिस्सों के लिए एक पूर्ण इवेंट-सोर्स्ड ऑडिट ट्रेल सुविधा के बजाय कानूनी आवश्यकता है, और यह तय करने का अधिकार किसके पास है? इवेंट सोर्सिंग और CQRS आपको एक परफ़ेक्ट, पुनर्निर्माण योग्य इतिहास और ऐसे रीड मॉडल देते हैं जो अपने आप स्केल करते हैं, लेकिन इनकी कीमत आपको सिस्टम के जीवनकाल भर इवेंट वर्ज़निंग, प्रोजेक्शन पुनर्निर्माण, और अंततः स्थिरता के बारे में तर्क करने में चुकानी पड़ती है। किसी ऐसे डोमेन पर लागू किया गया जिसे कभी ऑडिट ट्रेल की ज़रूरत नहीं थी, वह जटिलता शुद्ध कर है; किसी ऐसे डोमेन से रोक लिया गया जहाँ “हम इस मूल्य तक कैसे पहुँचे?” एक कानूनी प्रश्न है, इसकी अनुपस्थिति एक अनुपालन विफलता है। प्रतिस्पर्धी विचार एक तरफ़ ऑडिट योग्यता और क्वेरी स्केलेबिलिटी हैं, और दूसरी तरफ़ डीबगिंग कठिनाई और डेवलपर संज्ञानात्मक भार, इसलिए निर्णय उन लोगों का है जो नियामक दायित्व और परिचालन बोझ दोनों को समझते हैं, न कि जो भी पैटर्न के बारे में सबसे उत्साहित है। विशिष्ट कानूनी या संविदात्मक प्रतिधारण और पुनर्निर्माण आवश्यकताएँ, अपेक्षित इवेंट वॉल्यूम, और वर्ज़निंग व प्रोजेक्शन काम का एक ईमानदार अनुमान लाएँ। वित्त, कर, और सरकार में, जहाँ वर्षों बाद किसी निर्णय का पुनर्निर्माण एक वैधानिक कर्तव्य हो सकता है, उस जवाबदेह मालिक का नाम बताएँ जो यह स्वीकृति देता है कि दिया गया बाउंडेड कॉन्टेक्स्ट एक अपरिवर्तनीय इवेंट लॉग की आवश्यकता रखता है या नहीं।

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

क्षेत्र लेंस

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

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

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

विरोधी पैटर्न और नुकसान

• वितरित मोनोलिथ। ऐसी सेवाएँ जिन्हें साथ परिनियोजित होना चाहिए और एक डेटाबेस साझा करना चाहिए: वितरण की पूरी लागत, स्वतंत्रता में से कोई नहीं।
• नैनोसर्विसेज़। इतनी बारीक-दानेदार सेवाएँ कि ऑर्केस्ट्रेशन और नेटवर्क ओवरहेड उनके किए गए काम को बौना बना देते हैं।
• बिना प्लेटफ़ॉर्म के माइक्रोसर्विसेज़। CI/CD, ट्रेसिंग, और ऑन-कॉल परिपक्वता होने से पहले विभाजित करना; विफलता मोड गुणा हो जाते हैं।
• एंटिटी सेवाएँ। व्यावसायिक क्षमता के बजाय डेटाबेस टेबल के अनुसार विभाजित करना (“User service,” “Order service”), हर ऑपरेशन के लिए बातूनी क्रॉस-सर्विस कॉल को मजबूर करना।
• हर जगह इवेंट सोर्सिंग। इसे उन डोमेन पर लागू करना जिन्हें ऑडिट ट्रेल की ज़रूरत नहीं, बिना किसी लाभ के जटिलता कर चुकाना।
• मोनोलिथ के रूप में गेटवे। API गेटवे में व्यावसायिक लॉजिक डालना, एक केंद्रीय चोकपॉइंट को फिर से बनाना।
• फ्रेमवर्क-युक्त कोर। वेब या ORM (ऑब्जेक्ट-रिलेशनल मैपिंग) फ्रेमवर्क के साथ उलझा हुआ व्यावसायिक लॉजिक, जो टेस्टिंग और तकनीकी बदलाव दोनों को कष्टदायक बनाता है।

परिपक्वता मॉडल

• स्तर 1: आरंभ करें। शैली फ़ैशन या संयोग से चुनी जाती है। आपके पास एक उलझी हुई मोनोलिथ या एक आकस्मिक वितरित गड़बड़ी है, सीमाएँ डोमेन के बजाय तकनीकी परतों या इतिहास का अनुसरण करती हैं, और विभाजन तब प्रतिक्रियाशील रूप से होते हैं जब कुछ टूटता है।
• स्तर 2: विकसित करें। कुछ टीमें मोनोलिथ के अंदर जानबूझकर मॉड्यूल सीमाएँ खींचती हैं या कुछ मोटी सेवाएँ खड़ी करती हैं, और कुछ क्रॉस-कटिंग चिंताओं को लगातार संभाला जाता है। अभ्यास असमान है: एक समूह सेवाओं को बाउंडेड कॉन्टेक्स्ट के साथ संरेखित करता है जबकि दूसरा अभी भी डेटाबेस टेबल के अनुसार विभाजित करता है, और निष्कर्षण तदर्थ बना रहता है।
• स्तर 3: मानकीकृत करें। एक दस्तावेज़ीकृत दृष्टिकोण पूरे संगठन में लागू होता है: सेवाएँ बाउंडेड कॉन्टेक्स्ट के साथ संरेखित होती हैं और अपने डेटा की मालिक होती हैं, गेटवे और BFF पैटर्न जहाँ उपयुक्त हो उपयोग किए जाते हैं, आंतरिक क्लीन या हेक्सागोनल लेयरिंग मानक है, और हर विभाजन के लिए एक कहा गया चालक आवश्यक है। मॉड्यूल सीमाएँ टूलिंग द्वारा लागू की जाती हैं, केवल परंपरा से नहीं।
• स्तर 4: प्रबंधित करें। शैली निर्णयों को आधाररेखाओं के मुकाबले मापा और नियंत्रित किया जाता है। आप प्रति-सेवा परिनियोजन आवृत्ति और लीड टाइम, पुनर्प्राप्ति का औसत समय, एक सामान्य बदलाव के लिए कितनी सेवाओं को साथ परिनियोजित होना चाहिए, और नेटवर्क-हॉप लेटेंसी को ट्रैक करते हैं, और आप प्रत्येक विभाजन की लागत की तुलना उस स्वतंत्रता से करते हैं जो इसे ख़रीदनी थी। सबूत, पसंद नहीं, यह तय करता है कि कोई सीमा टिकती है या नहीं, और वितरित मोनोलिथ की ओर बहाव किसी आउटेज के बजाय मीट्रिक द्वारा पकड़ा जाता है।
• स्तर 5: समन्वित करें। आर्किटेक्चर संगठन डिज़ाइन के साथ एकीकृत है और लगातार अनुकूलित होता है। एक परिपक्व प्लेटफ़ॉर्म (CI/CD, ट्रेसिंग, और जहाँ उचित हो मेश) वितरण और पुनर्समेकन दोनों को सस्ता बनाता है, टीमें नियमित रूप से तब निकालती हैं जब कोई चालक दिखाई देता है और सेवाओं को वापस मोड़ती हैं जब वह गायब हो जाता है, और शैली के चुनाव पूरी संपत्ति में टीम टोपोलॉजी, लोड, और जोखिम की तस्वीर बदलने के साथ पुनर्संतुलित किए जाते हैं।

चर्चा के लिए विचार

1. आपके सिस्टम में मोनोलिथ वास्तव में कहाँ एक ताकत है, और कहाँ यह एक वास्तविक बाधा है?
2. कौन सा ठोस चालक आपकी अगली सेवा को निकालने को उचित ठहराएगा, और क्या आप इसे बनाने से पहले इसका नाम बता सकते हैं?
3. क्या आपके संगठन के पास वह परिचालन परिपक्वता है जो माइक्रोसर्विसेज़ मांगती हैं? क्या कमी है?
4. आपके डोमेन के किन हिस्सों के लिए एक पूर्ण इवेंट-सोर्स्ड ऑडिट ट्रेल एक कानूनी या व्यावसायिक आवश्यकता है, बनिस्बत एक अच्छे-से-होने के?
5. आपकी वर्तमान सेवा सीमाएँ आपकी टीम सीमाओं को कितनी अच्छी तरह प्रतिबिंबित करती हैं, और क्या वह संरेखण मदद कर रहा है या नुकसान पहुँचा रहा है?
6. यदि आपको अगले साल अपना वेब फ्रेमवर्क या डेटाबेस बदलना पड़े, तो आपको अपने व्यावसायिक लॉजिक का कितना हिस्सा फिर से लिखना पड़ेगा?

मुख्य निष्कर्ष

• आर्किटेक्चरल शैली को वास्तविक बलों (टीम का आकार, डोमेन, लोड, परिचालन परिपक्वता) से चुनें, फ़ैशन से नहीं।
• अधिकांश सिस्टम के लिए एक मॉड्यूलर मोनोलिथ सही डिफ़ॉल्ट है; केवल किसी ठोस चालक के साथ और बाउंडेड-कॉन्टेक्स्ट रेखाओं के साथ सेवाएँ निकालें।
• माइक्रोसर्विसेज़ स्वतंत्र परिनियोजन, स्केलिंग, और दोष अलगाव के लिए परिचालन और संज्ञानात्मक जटिलता का व्यापार करती हैं; उन्हें एक परिपक्व प्लेटफ़ॉर्म चाहिए।
• इवेंट-संचालित, CQRS, और इवेंट सोर्सिंग अंततः स्थिरता और वर्ज़निंग जटिलता की कीमत पर डीकपलिंग और ऑडिट योग्यता प्रदान करते हैं; इन्हें जानबूझकर अपनाएँ।
• गेटवे, BFF, और मेश कई-सेवा संपत्तियों को वश में करते हैं लेकिन भार जोड़ते हैं; इन्हें तब पेश करें जब पैमाना मांग करे, उससे पहले नहीं।
• मूल्यवान व्यावसायिक लॉजिक को टेस्टेबल और तकनीकी बदलावों में टिकाऊ रखने के लिए हर सेवा के अंदर हेक्सागोनल/क्लीन आर्किटेक्चर लागू करें।

संदर्भ और आगे पढ़ने के लिए

• Sam Newman, Building Microservices and Monolith to Microservices
• Chris Richardson, Microservices Patterns
• Eric Evans, Domain-Driven Design
• Vaughn Vernon, Implementing Domain-Driven Design
• Robert C. Martin, Clean Architecture
• Alistair Cockburn, “Hexagonal Architecture (Ports and Adapters)”
• Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
• Martin Fowler, Patterns of Enterprise Application Architecture (और CQRS व Event Sourcing पर लेख)
• Matthew Skelton and Manuel Pais, Team Topologies