वितरित प्रणालीहरूमा विश्वसनीय सन्देश

दोहोरो लेखन समस्या भरपर्दो, अत्यधिक उपलब्ध, स्केलेबल वितरण प्रणाली निर्माण गर्न विशेष प्रविधि, सिद्धान्त र ढाँचाहरूको पालना आवश्यक छ। त्यस्ता प्रणालीहरूको डिजाइनमा असंख्य चुनौतीहरूलाई सम्बोधन गर्न समावेश छ। सबैभन्दा प्रचलित र आधारभूत समस्याहरू मध्ये हो। दोहोरो लेखन समस्या एक चुनौती हो जुन वितरित प्रणालीहरूमा उत्पन्न हुन्छ, मुख्यतया धेरै डेटा स्रोतहरू वा डाटाबेसहरूसँग व्यवहार गर्दा जुन सिङ्कमा राख्न आवश्यक छ। यसले डाटाको असंगति, विवाद, वा कार्यसम्पादन बाधाहरू जस्ता मुद्दाहरूको परिचय नगरी डाटाबेस वा क्यासहरू जस्ता विभिन्न डाटा स्टोरहरूमा डाटा परिवर्तनहरू निरन्तर रूपमा लेखिएको छ भनी सुनिश्चित गर्न कठिनाइलाई जनाउँछ। "दोहोरो लेखन समस्या" माइक्रोसर्भिसेस आर्किटेक्चर र ढाँचा डाटाबेस प्रति सेवाले तपाईंलाई धेरै फाइदाहरू ल्याउँछ, जस्तै स्वतन्त्र तैनाती र स्केलिंग, पृथक विफलताहरू, र विकास वेगको सम्भावित वृद्धि। यद्यपि, अपरेसनहरूलाई धेरै माइक्रोसर्भिसहरू बीच परिवर्तनहरू आवश्यक पर्दछ, तपाईंलाई यो समस्या समाधान गर्न भरपर्दो समाधानको बारेमा सोच्न बाध्य पार्छ। लगभग एक वास्तविक उदाहरण एउटा परिदृश्यलाई विचार गरौं जसमा हाम्रो डोमेनले ऋण आवेदनहरू स्वीकार गर्ने, तिनीहरूको मूल्याङ्कन गर्ने, र त्यसपछि ग्राहकहरूलाई सूचना अलर्टहरू पठाउने समावेश गर्दछ। एकल जिम्मेवारी सिद्धान्त, कोन्वेको कानून, र डोमेन-संचालित डिजाइन दृष्टिकोणको भावनामा, धेरै घटना-तुफान सत्रहरू पछि, सम्पूर्ण डोमेनलाई स्पष्ट सीमाहरू, डोमेन मोडेलहरू, र सर्वव्यापी भाषा भएको परिभाषित बाउन्ड गरिएको सन्दर्भहरू सहित तीन उप-डोमेनहरूमा विभाजित गरिएको थियो। अनबोर्डिङ र नयाँ ऋण आवेदनहरू संकलन गर्ने काम दिइएको छ। प्रणालीले यी अनुप्रयोगहरूको मूल्याङ्कन गर्दछ र प्रदान गरिएको डाटाको आधारमा निर्णय गर्दछ। यो मूल्याङ्कन प्रक्रिया, KYC/KYB, एन्टिफ्राड, र क्रेडिट जोखिम जाँचहरू सहित, समय-खपत हुन सक्छ, एकै साथ हजारौं आवेदनहरू ह्यान्डल गर्ने क्षमता आवश्यक हुन्छ। फलस्वरूप, यो कार्यक्षमता स्वतन्त्र स्केलिंगको लागि अनुमति दिँदै आफ्नै डाटाबेसको साथ समर्पित माइक्रोसर्भिसलाई प्रत्यायोजित गरिएको छ। पहिलोलाई दोस्रो यसबाहेक, यी उपप्रणालीहरू दुई फरक टोलीहरूद्वारा व्यवस्थित हुन्छन्, प्रत्येकको आफ्नै रिलीज चक्र, सेवा स्तर सम्झौताहरू (SLA), र स्केलेबिलिटी आवश्यकताहरू। , ग्राहकहरूलाई अलर्टहरू पठाउनको लागि एक विशेष सूचना सेवा स्थानमा छ। अन्तमा यहाँ प्रणाली को प्राथमिक उपयोग मामला को एक परिष्कृत विवरण छ: एक ग्राहकले ऋण आवेदन पेश गर्दछ। Loan Application Service ले नयाँ आवेदनलाई "Pending" स्थितिको साथ रेकर्ड गर्छ र आवेदनलाई मूल्याङ्कन सेवामा फर्वार्ड गरेर मूल्याङ्कन प्रक्रिया प्रारम्भ गर्छ। मूल्याङ्कन सेवाले आगमन ऋण आवेदनको मूल्याङ्कन गर्दछ र पछि निर्णयको बारेमा ऋण आवेदन सेवालाई सूचित गर्दछ। निर्णय प्राप्त गरेपछि, ऋण आवेदन सेवाले तदनुसार ऋण आवेदन स्थिति अद्यावधिक गर्दछ र परिणामको ग्राहकलाई सूचित गर्न सूचना सेवा ट्रिगर गर्दछ। सूचना सेवाले यस अनुरोधलाई प्रशोधन गर्छ र ग्राहकको सेटिङहरू अनुसार इमेल, एसएमएस वा अन्य मनपर्ने सञ्चार विधिहरू मार्फत ग्राहकलाई सूचनाहरू पठाउँछ। यो पहिलो नजर मा एक धेरै सरल र आदिम प्रणाली हो, तर हामी कसरी ऋण आवेदन सेवा पेश ऋण आवेदन आदेश प्रक्रिया मा डुब्न गरौं। हामी सेवा अन्तरक्रियाको लागि दुई दृष्टिकोणहरू विचार गर्न सक्छौं: यस दृष्टिकोणमा, सेवाले आफ्नो स्थानीय डाटाबेस (कमिटहरू) अद्यावधिक गर्दछ र त्यसपछि अन्य सेवाहरूमा घटना वा सन्देश प्रकाशित गर्दछ। पहिलो-स्थानीय-कमिट-त्यसपछि-प्रकाशन: यसको विपरीत, यो विधिले स्थानीय डाटाबेसमा परिवर्तनहरू कमिट गर्नु अघि घटना वा सन्देश प्रकाशित गर्न समावेश गर्दछ। पहिलो-प्रकाशन-त्यसपछि-स्थानीय-कमिट: दुबै विधिहरूमा तिनीहरूको कमजोरीहरू छन् र वितरण प्रणालीहरूमा सञ्चारको लागि आंशिक रूपमा असफल-सुरक्षित छन्। यो पहिलो दृष्टिकोण लागू गर्ने अनुक्रम रेखाचित्र हो। यस परिदृश्यमा, ऋण आवेदन सेवाले दृष्टिकोण प्रयोग गर्दछ, जहाँ यसले पहिले लेनदेन गर्छ र त्यसपछि अर्को प्रणालीमा सूचना पठाउने प्रयास गर्दछ। यद्यपि, यो प्रक्रिया विफलताको लागि संवेदनशील छ यदि, उदाहरणका लागि, त्यहाँ नेटवर्क समस्याहरू छन्, मूल्याङ्कन सेवा उपलब्ध छैन, वा लोन आवेदन सेवाले मेमोरी आउट (OOM) त्रुटि र क्र्यासको सामना गर्दछ। त्यस्ता अवस्थाहरूमा, सन्देश हराउनेछ, नयाँ ऋण आवेदनको सूचना बिना मूल्याङ्कन छोडेर, अतिरिक्त उपायहरू लागू नभएसम्म। पहिलो-स्थानीय-कमिट-त्यसपछि-प्रकाशन र दोस्रो। परिदृश्यमा, ऋण आवेदन सेवाले धेरै महत्त्वपूर्ण जोखिमहरूको सामना गर्दछ। यसले नयाँ अनुप्रयोगको बारेमा मूल्याङ्कन सेवालाई सूचित गर्न सक्छ तर डाटाबेस समस्याहरू, मेमोरी त्रुटिहरू, वा कोड बगहरू जस्ता समस्याहरूको कारणले स्थानीय रूपमा यो अद्यावधिक बचत गर्न असफल हुन्छ। यो दृष्टिकोणले डेटामा महत्त्वपूर्ण विसंगतिहरू निम्त्याउन सक्छ, जसले गम्भीर समस्याहरू निम्त्याउन सक्छ, ऋण समीक्षा सेवाले आगमन अनुप्रयोगहरूलाई कसरी ह्यान्डल गर्छ भन्ने आधारमा। पहिलो-प्रकाशन-तब-स्थानीय-कमिट तसर्थ, हामीले बाह्य उपभोक्ताहरूलाई घटनाहरू प्रकाशित गर्नको लागि बलियो संयन्त्र प्रदान गर्ने समाधान पहिचान गर्नुपर्छ। तर, सम्भावित समाधानहरू खोज्नु अघि, हामीले वितरण प्रणालीहरूमा प्राप्त गर्न सकिने सन्देश वितरण ग्यारेन्टीको प्रकारहरू स्पष्ट गर्नुपर्छ। सन्देश वितरण ग्यारेन्टी हामीले प्राप्त गर्न सक्ने चार प्रकारका ग्यारेन्टीहरू छन्। कुनै ग्यारेन्टी छैन सन्देश गन्तव्यमा पुर्याउने कुनै ग्यारेन्टी छैन। दृष्टिकोण यस विषयमा हो। उपभोक्ताहरूले सन्देशहरू एक पटक, धेरै पटक वा कहिल्यै प्राप्त गर्न सक्छन्। पहिले-स्थानीय-समिति-त्यसपछि-प्रकाशित गर्ने बढीमा एक पटक डेलिभरी धेरैमा एक पटक डेलिभरीको अर्थ हो कि सन्देश गन्तव्यमा अधिकतम 1 पटक डेलिभर गरिनेछ। दृष्टिकोण यसरी लागू गर्न सकिन्छ र मूल्य एकको साथ प्रयासहरूको पुन: प्रयास नीतिको साथ। पहिलो-स्थानीय-कमिट-त्यसपछि-प्रकाशन कम्तिमा एक पटक डेलिभरी\उपभोक्ताहरूले प्रत्येक सन्देश प्राप्त गर्नेछन् र प्रशोधन गर्नेछन् तर एउटै सन्देश एक पटक भन्दा बढी प्राप्त गर्न सक्छन्। ठ्याक्कै एकचोटि डेलिभरी\एकपटक मात्र डेलिभरीको अर्थ उपभोक्ताले सन्देश एक पटक प्रभावकारी रूपमा प्राप्त गर्नेछन्। प्राविधिक रूपमा, यो काफ्का लेनदेनहरू र उत्पादक र उपभोक्ताको विशिष्ट अदम्य कार्यान्वयनबाट प्राप्त गर्न सम्भव छ। धेरैजसो अवस्थामा, डेलिभरीले सन्देशहरू कम्तिमा एक पटक डेलिभर भएको सुनिश्चित गरेर धेरै समस्याहरूलाई सम्बोधन गर्ने ग्यारेन्टी दिन्छ, तर उपभोक्ताहरू निर्दोष हुनुपर्छ। यद्यपि, अपरिहार्य सञ्जाल विफलताहरू दिएर, सबै उपभोक्ता तर्कहरू नक्कल सन्देशहरू प्रशोधन गर्नबाट बच्नको लागि निर्दयी हुनुपर्छ, निर्माताको ग्यारेन्टीहरू बिना। तसर्थ, यो आवश्यकता वास्तविकतालाई प्रतिबिम्बित गर्ने जति धेरै कमजोरी होइन। 'कम्तीमा एक पटक' समाधानहरू यस समस्याको धेरै समाधानहरू छन्, जसको फाइदा र बेफाइदाहरू छन्। दुई-चरण प्रतिबद्धता विकिपिडियाका अनुसार, दुई-चरण कमिट (2PC) एक वितरित लेनदेन प्रोटोकल हो जुन कम्प्युटर विज्ञान र डाटाबेस व्यवस्थापन प्रणालीहरूमा वितरित लेनदेनको स्थिरता र विश्वसनीयता सुनिश्चित गर्न प्रयोग गरिन्छ। यो परिस्थितिहरूको लागि डिजाइन गरिएको हो जहाँ बहु स्रोतहरू (जस्तै, डाटाबेसहरू) एकल लेनदेनमा भाग लिन आवश्यक छ, र यसले सुनिश्चित गर्दछ कि या त ती सबै लेनदेन गर्छन् वा ती सबैले यसलाई रद्द गर्छन्, जसले गर्दा डेटा स्थिरता कायम राख्छ। यो ठ्याक्कै हामीलाई चाहिएको जस्तो देखिन्छ, तर दुई-चरण कमिटमा धेरै कमजोरीहरू छन्: यदि एक सहभागी स्रोत अनुत्तरदायी भयो वा असफलताको अनुभव भयो भने, समस्या समाधान नभएसम्म सम्पूर्ण प्रक्रिया अवरुद्ध हुन सक्छ। यसले सम्भावित प्रदर्शन र उपलब्धता समस्याहरू निम्त्याउन सक्छ। दुई-चरण प्रतिबद्धताले निर्मित त्रुटि सहिष्णुता संयन्त्र प्रदान गर्दैन। यो असफलताहरू ह्यान्डल गर्न बाह्य संयन्त्र वा म्यानुअल हस्तक्षेपमा निर्भर हुन्छ। सबै आधुनिक डाटाबेसले दुई-चरण प्रतिबद्धतालाई समर्थन गर्दैन। साझा डाटाबेस माइक्रोसर्भिसेस आर्किटेक्चरको लागि सबैभन्दा स्पष्ट समाधान भनेको ढाँचा (वा कहिलेकाहीँ एन्टि-प्याटर्न) - साझा डाटाबेस लागू गर्नु हो। यो दृष्टिकोण धेरै सहज छ यदि तपाईंलाई विभिन्न डाटाबेसहरूमा धेरै तालिकाहरूमा लेनदेन स्थिरता चाहिन्छ भने, यी माइक्रो सेवाहरूको लागि केवल एउटा साझा डाटाबेस प्रयोग गर्नुहोस्। यस दृष्टिकोणका कमजोरीहरूमा विफलताको एकल बिन्दु परिचय, स्वतन्त्र डाटाबेस स्केलिंगलाई रोक्न, र विशिष्ट आवश्यकताहरू र प्रयोग केसहरूको लागि उपयुक्त विभिन्न डेटाबेस समाधानहरू प्रयोग गर्ने क्षमतालाई सीमित गर्ने समावेश छ। थप रूपमा, वितरित लेनदेनको यस्तो रूपलाई समर्थन गर्न माइक्रोसर्भिसेस कोडबेसहरूमा परिमार्जनहरू आवश्यक हुनेछ। लेनदेन आउटबक्स ' ' एक डिजाईन ढाँचा हो जुन वितरित प्रणालीहरूमा प्रयोग गरिन्छ विश्वसनीय सन्देश प्रसार सुनिश्चित गर्न, अविश्वसनीय सन्देश प्रणालीहरूको सामना गर्दा पनि। यसले सञ्चालनको रूपमा नै लेनदेन भित्र निर्दिष्ट 'आउटबक्स घटनाहरू' तालिकामा घटनाहरू भण्डारण गर्न समावेश गर्दछ। यो दृष्टिकोण रिलेसनल डाटाबेसको ACID गुणहरूसँग राम्रोसँग पङ्क्तिबद्ध छ। यसको विपरित, धेरै No-SQL डाटाबेसहरूले ACID गुणहरूलाई पूर्ण रूपमा समर्थन गर्दैनन्, यसको सट्टा CAP प्रमेय र BASE दर्शनका सिद्धान्तहरूको लागि रोज्छन्, जसले कडा स्थिरतामा उपलब्धता र अन्तिम स्थिरतालाई प्राथमिकता दिन्छ। ट्रान्जेक्शनल आउटबक्स एक लेनदेन आउटबक्स प्रदान गर्दछ र धेरै दृष्टिकोण संग लागू गर्न सकिन्छ: कम्तिमा एक पटक ग्यारेन्टी लेनदेन लग टेलिङ मतदान प्रकाशक दृष्टिकोणले डाटाबेस-विशिष्ट समाधानहरू जस्तै CDC (डेटा क्याप्चर परिवर्तन गर्नुहोस्) प्रयोग गरी बुझाउँछ। यस दृष्टिकोणको मुख्य कमजोरीहरू हुन्: लेनदेन लग टेलिङ डाटाबेस विशिष्ट समाधान CDC कार्यान्वयनको विशिष्टताका कारण विलम्बता बढेको छ अर्को विधि हो, जसले आउटबक्स तालिकामा मतदान गरेर आउटबक्स अफलोड गर्ने सुविधा दिन्छ। यस दृष्टिकोणको प्राथमिक कमजोरी भनेको डाटाबेस लोड बढेको सम्भावना हो, जसले उच्च लागत निम्त्याउन सक्छ। यसबाहेक, सबै No-SQL डाटाबेसहरूले विशिष्ट कागजात खण्डहरूको लागि कुशल क्वेरी समर्थन गर्दैन। सम्पूर्ण कागजातहरू निकाल्दा कार्यसम्पादनमा ह्रास आउन सक्छ। पोलिंग पब्लिशर यहाँ एउटा सानो अनुक्रम रेखाचित्र छ यसले कसरी काम गर्छ भनेर वर्णन गर्दछ। आफै सुन्नुहोस् लेनदेन आउटबक्स ढाँचाको साथ प्राथमिक चुनौती डाटाबेस ACID गुणहरूमा निर्भरतामा छ। यो सामान्य OLTP डाटाबेसहरूमा सीधा हुन सक्छ तर NoSQL दायरामा चुनौतीहरू खडा गर्दछ। यसलाई सम्बोधन गर्नको लागि, सम्भावित समाधान भनेको एपेन्ड लग (उदाहरणका लागि, काफ्का) लाई अनुरोध प्रशोधन प्रारम्भ गर्नबाट नै लाभ उठाउनु हो। 'लोन आवेदन पेश गर्नुहोस्' आदेशलाई सीधै प्रशोधन गर्नुको सट्टा, हामी यसलाई तुरुन्तै आन्तरिक काफ्का शीर्षकमा पठाउँछौं र त्यसपछि ग्राहकलाई 'स्वीकृत' नतिजा फर्काउँछौं। यद्यपि, कमाण्डलाई अझै प्रशोधन गर्न आवश्यक छ भन्ने धेरै सम्भावना भएकोले, हामी तुरुन्तै परिणामको ग्राहकलाई सूचित गर्न सक्दैनौं। यो अन्तिम स्थिरता व्यवस्थापन गर्न, हामी प्रविधिहरू प्रयोग गर्न सक्छौं जस्तै लामो मतदान, ग्राहक-प्रारम्भिक मतदान, आशावादी UI अद्यावधिकहरू, वा सूचनाहरूको लागि WebSockets वा सर्भर-पठाइएका घटनाहरू प्रयोग गरेर। यद्यपि, यो पूर्ण रूपमा एक फरक विषय हो, त्यसैले हामी हाम्रो प्रारम्भिक विषयमा फर्कौं। हामीले आन्तरिक काफ्का विषयमा सन्देश पठायौं। लोन एप्लिकेसन सेवाले त्यसपछि यो सन्देश उपभोग गर्छ — ग्राहकबाट प्राप्त भएको उही आदेश — र प्रक्रिया सुरु हुन्छ। पहिलो, यसले केही व्यापार तर्कहरू कार्यान्वयन गर्दछ; यो तर्कलाई सफलतापूर्वक कार्यान्वयन गरिसकेपछि र नतिजा कायम रहेपछि, यसले सार्वजनिक काफ्का विषयमा नयाँ सन्देशहरू प्रकाशित गर्दछ। हामी छद्म कोड को एक बिट मा एक नजर राखौं। public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); } चिन्ता नलिनुहोस्, अफसेट अझै कमिट गरिएको छैन, सन्देश पुन: प्रयास गरिनेछ। व्यापार तर्कको प्रशोधन असफल भयो भने के हुन्छ? चिन्ता नलिनुहोस्, किनकि व्यवसायको तर्क कमजोर छ, यसले डुप्लिकेट ऋण आवेदन सिर्जना गर्दैन। यसको सट्टा, यसले सार्वजनिक काफ्का विषयमा सन्देशहरू पुन: पठाउने प्रयास गर्नेछ। यदि काफ्कालाई नयाँ घटनाहरू पठाउन असफल भयो भने के हुन्छ? चिन्ता नलिनुहोस्, किनकि व्यवसायको तर्क कमजोर छ, यसले डुप्लिकेट ऋण आवेदन सिर्जना गर्दैन। यसको सट्टा, यसले सार्वजनिक काफ्का विषयलाई सन्देशहरू पुन: पठाउनेछ र आशा गर्दछ कि अफसेट प्रतिबद्धता यस पटक सफल हुन्छ। यदि काफ्कालाई सन्देशहरू पठाइन्छ, तर अफसेट प्रतिबद्धता असफल भयो भने के हुन्छ? यस दृष्टिकोणका मुख्य कमजोरीहरूमा नयाँ प्रोग्रामिङ शैलीसँग जोडिएको जटिलता, अन्तिम स्थिरता (क्लान्टले तुरुन्तै नतिजा थाहा नपाउने भएकाले), र सबै व्यवसायिक तर्कलाई कमजोर हुनको लागि आवश्यकता समावेश गर्दछ। घटना स्रोत घटना सोर्सिङ के हो, र यसलाई यहाँ कसरी लागू गर्न सकिन्छ? घटना सोर्सिङ एक सफ्टवेयर आर्किटेक्चरल ढाँचा हो जुन प्रणालीको अवस्थालाई मोडेल गर्न प्रयोग गरिन्छ यसको डेटामा सबै परिवर्तनहरू अपरिवर्तनीय घटनाहरूको श्रृंखलाको रूपमा कब्जा गरेर। यी घटनाहरूले तथ्य वा राज्यको संक्रमणलाई प्रतिनिधित्व गर्दछ र प्रणालीको वर्तमान अवस्थाको लागि सत्यको एकल स्रोतको रूपमा सेवा गर्दछ। त्यसोभए, प्राविधिक रूपमा, घटना-सोर्सिङ प्रणाली लागू गरेर, हामीसँग पहिले नै EventStore मा सबै घटनाहरू छन्, र यो घटनास्टोर उपभोक्ताहरूले के भयो भन्ने बारे सत्यको एकल स्रोतको रूपमा प्रयोग गर्न सक्छन्। आदेशको बारेमा सबै परिवर्तनहरू वा चिन्ताहरू ट्र्याक गर्नको लागि कुनै विशेष डाटाबेस समाधानको आवश्यकता छैन, केवल समस्या पढ्ने पक्षमा बसिरहेको छ किनकि संस्थाको वास्तविक स्थिति प्राप्त गर्न सक्षम हुन सबै घटनाहरू पुन: प्ले गर्न आवश्यक छ। निष्कर्ष यस लेखमा, हामीले वितरित प्रणालीहरूमा भरपर्दो सन्देश निर्माण गर्नका लागि धेरै दृष्टिकोणहरूको समीक्षा गर्यौं। यी विशेषताहरूसँग प्रणालीहरू निर्माण गर्दा हामीले विचार गर्न सक्ने थुप्रै सिफारिसहरू छन् नेटवर्क विफलता अपरिहार्य भएकोले सधैं कमजोर उपभोक्ताहरू विकास गर्नुहोस्। ग्यारेन्टी आवश्यकताहरूको स्पष्ट बुझाइको साथ सावधानीपूर्वक प्रयोग गर्नुहोस्। पहिलो-स्थानीय-कमिट-त्यसपछि-प्रकाशनलाई दृष्टिकोण कहिल्यै प्रयोग नगर्नुहोस् किनकि यसले तपाईंको प्रणालीमा गम्भीर डेटा असंगतता निम्त्याउन सक्छ। पहिलो-प्रकाशन-त्यसपछि-स्थानीय-कमिट यदि अवस्थित डाटाबेस छनोट निर्णय धेरै सम्भावित परिवर्तन हुन सक्छ वा प्राविधिक रणनीतिले समस्याको लागि उत्तम भण्डारण समाधान चयन गर्न संकेत गर्दछ — जस्ता डाटाबेस समाधानहरूमा बाँधिएर साझा पुस्तकालयहरू निर्माण नगर्नुहोस्। CDC कम्तिमा एक पटक ग्यारेन्टीहरू प्राप्त गर्नको लागि मानक समाधानको रूपमा दृष्टिकोण प्रयोग गर्नुहोस्। लेनदेन आउटबक्स No-SQL डाटाबेसहरू लिभरेज हुँदा दृष्टिकोण प्रयोग गर्ने बारे विचार गर्नुहोस्। Listen to Yourself अर्को पटक, हामी लेनदेन आउटबक्स लागू गर्ने थप व्यावहारिक उदाहरण हेर्नेछौं। हेर्नुहोस् तिमी!