आधुनिक लेन-देन ढेर

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

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

और इसलिए, एक उद्योग के रूप में, हम बढ़ती जागरूकता देख रहे हैं कि पारंपरिक मॉडल के बाहर लेनदेन संबंधी गारंटी की आवश्यकता है। हम देख रहे हैं ऐसी प्रणालियों का उद्भव जो डेटाबेस से परे, वितरित ऐप्स में भी मजबूत लेनदेन संबंधी गारंटी प्रदान करते हैं. 

हम पिछले कुछ वर्षों से इन समाधानों पर नज़र रख रहे हैं। आम तौर पर, वे स्केलिंग चुनौतियां पैदा किए बिना और एक आधुनिक प्रोग्रामिंग वातावरण प्रदान करते हुए, एक बड़े वितरित ऐप में राज्य के लेनदेन प्रबंधन की अनुमति देने का प्रयास करते हैं। 

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

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

हालाँकि, इन नए ढेरों की जांच करने से पहले, यह समझने में सहायता के लिए एक त्वरित अर्ध-तकनीकी विषयांतर है कि हम यहां तक ​​कैसे पहुंचे।

लेन-देन, गारंटी और आधुनिक ऐप्स 

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

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

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

परिभाषाएँ व्यावसायिक डेटा ("डेटा") दृढ़ता और प्रसंस्करण के लिए पारंपरिक रूप से ओएलटीपी डेटाबेस में संग्रहीत व्यवसाय-महत्वपूर्ण डेटा को संदर्भित करता है (उदाहरण के लिए उपयोगकर्ता प्रोफ़ाइल जानकारी जैसे नाम, पता, क्रेडिट स्कोर इत्यादि)। आवेदन स्थिति सिस्टम की वर्तमान स्थिति को संदर्भित करता है; एप्लिकेशन की स्थिति डेटा स्टोरेज सिस्टम में संग्रहीत मूल्य द्वारा निर्धारित की जाती है और प्रोग्राम का निष्पादन एक सीमित राज्य मशीन में किस चरण पर होता है (उदाहरण के लिए ऑर्डर की स्थिति, जैसे "ऑर्डर प्राप्त हुआ," "इन्वेंट्री की जांच की गई," "क्रेडिट की जांच की गई) ," "भेज दिया गया," "लौटा दिया गया")। व्यापार का तर्क प्रोग्राम के उस हिस्से को संदर्भित करता है जो निष्पादन विवरण के बजाय एप्लिकेशन वास्तव में कैसे काम करता है या यह क्या करता है, से संबंधित है (उदाहरण के लिए "यदि उपयोगकर्ता आय> $ 100K और क्रेडिट_स्कोर> 650 ⇒ बंधक_अनुमोदित = TRUE")।

इस चर्चा के प्रयोजनों के लिए, एप्लिकेशन स्थिति और व्यावसायिक डेटा में अंतर करना महत्वपूर्ण है। उदाहरण के लिए, यह जानना कि ग्राहक ने अपना क्रेडिट कार्ड दर्ज किया है लेकिन चेक आउट नहीं किया है, आवेदन स्थिति है। क्रेडिट कार्ड का डेटा और एप्लिकेशन कार्ट में आइटम व्यावसायिक डेटा हैं। 

एक सामान्य प्रवाह में, एक अनुरोध फ्रंट-एंड से आता है, प्रमाणित किया जाता है, और फिर एपीआई गेटवे या ग्राफक्यूएल के माध्यम से संबंधित एंडपॉइंट पर भेजा जाता है। 

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

जैसे-जैसे एप्लिकेशन का पैमाना बढ़ता है, वैसे-वैसे कतारों और कैशों को प्रबंधित करने की जटिलता भी बढ़ती है, साथ ही समस्या आने पर समाधान तर्क में तेज किनारों की संख्या भी बढ़ती है। 

वर्कफ़्लो-केंद्रित और डेटाबेस-केंद्रित लेनदेन संबंधी स्टैक का उदय

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

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

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

वर्कफ़्लो-केंद्रित दृष्टिकोण विस्तार से 

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

उदाहरण के तौर पर, ऑर्केस (कंडक्टर) पर चल रहे चेक-आउट वर्कफ़्लो का एक दृश्य प्रतिनिधित्व नीचे दिया गया है: 

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

नकारात्मक पक्ष यह है कि एप्लिकेशन डेवलपर्स के लिए उपयोगी और सुरक्षित इंटरफेस को उजागर करने के लिए अक्सर बहुत सारे एकीकरण कार्य और रैपर कोड की आवश्यकता होती है। एक और नकारात्मक पक्ष यह है कि यह मूल भाषा के बजाय एक कस्टम निष्पादन परत पर निर्भर करता है, और ऐसे किनारे के मामले हैं जहां निष्पादन मूल भाषा रनटाइम से भिन्न होगा। इसलिए, जबकि डेवलपर्स उन भाषाओं का उपयोग कर सकते हैं जिनसे वे परिचित हैं, फिर भी उन्हें यह समझने की आवश्यकता है कि अंतर्निहित सिस्टम कैसे काम करता है।  

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

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

हालाँकि यह आज आदर्श नहीं है, हम वैचारिक वास्तुकला का वर्णन करना चाहते हैं कि कैसे कई मामलों में वर्कफ़्लो का उपयोग लगातार डेटा स्टोर के रूप में किया जा सकता है:

डेटाबेस-केंद्रित दृष्टिकोण विस्तार से 

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

दरअसल, शुद्ध डेटाबेस दृश्य यह है कि एप्लिकेशन स्थिति हमेशा व्यावसायिक डेटा से प्राप्त की जा सकती है। यह आमतौर पर एप्लिकेशन स्थिति को लेनदेन के एक सेट के रूप में संग्रहीत करके किया जाता है जो डेटाबेस में व्यावसायिक डेटा को संशोधित करता है। इसे एक डेटाबेस के रूप में सोचना सबसे आसान है जो ऊपर वर्णित वर्कफ़्लो सिस्टम के समान मजबूत गारंटी के साथ कोड के ब्लॉक निष्पादित कर सकता है। 

आंतरिक रूप से, हम इसे कहते हैं एप्लिकेशन लॉजिक ट्रांजेक्शनल प्लेटफ़ॉर्म (एएलटीपी) दृष्टिकोण क्योंकि, अंततः, यह एप्लिकेशन में ओएलटीपी लेनदेन का विस्तार करता है। लेकिन वास्तव में एएलटीपी की विशेषता यह है कि, ग्रीनफील्ड ऐप्स के लिए, यह ऐप डेवलपर्स के लिए सीधे बैक-एंड इंफ्रास्ट्रक्चर को प्रबंधित करने की आवश्यकता को पूरी तरह से समाप्त कर सकता है।  

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

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

एएलटीपी वर्कफ़्लो इंजनों को डेटाबेस से अलग करने की समस्या को हल करता है, लेकिन इसके परिणामस्वरूप, उपयोगकर्ताओं को लाभ प्राप्त करने के लिए मानक ओएलटीपी के बजाय अपने डेटाबेस की पेशकश पर भरोसा करने की आवश्यकता होती है। परिणामस्वरूप, हम मुख्य रूप से टीमों को मौजूदा, जटिल बैकएंड में एकीकृत करने के बजाय, ग्रीनफ़ील्ड ऐप्स के लिए ALTP को अपनाते हुए देखते हैं।

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

अभिसरण

यह स्पष्ट होता जा रहा है कि वर्कफ़्लो-केंद्रित दृष्टिकोण और डेटाबेस-केंद्रित दृष्टिकोण टकराव के रास्ते पर हैं। इसका प्राथमिक कारण यह है कि जबकि एप्लिकेशन स्थिति और डेटाबेस स्थिति तार्किक रूप से अलग हैं, वे एक-दूसरे पर निर्भर हैं, और एक प्रणाली जो दोनों को कवर नहीं करती है उसे सही करना और डीबग करना जटिल है।  

उदाहरण के तौर पर, उपयोगकर्ता की चेकआउट प्रक्रिया के लिए राज्य मशीन को ट्रैक करने के लिए उपयोग किए जा रहे वर्कफ़्लो इंजन पर विचार करें, और वह उपयोगकर्ता कार्ट में एक आइटम जोड़ रहा है। आमतौर पर, वर्कफ़्लो इंजन यह सुनिश्चित करते हैं कि विफलता की स्थिति में भी एक कोड चरण चलेगा। हालाँकि, ऐसे उदाहरण हो सकते हैं जहाँ इंजन को विफलता के दौरान दिए गए चरण को फिर से चलाने की आवश्यकता होती है क्योंकि यह पूरी तरह से निश्चित नहीं है कि चरण पूरी तरह से पूरा हो गया है या नहीं। यदि उस चरण में पारंपरिक डेटाबेस (इस मामले में, कार्ट में आइटम) में व्यावसायिक डेटा लिखना शामिल है और डेटाबेस को डुप्लिकेट पुनः प्रयास के बारे में पता नहीं है, तो यह डुप्लिकेट प्रविष्टि के साथ समाप्त हो जाएगा। 

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

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

जैसा कि इयान लिविंगस्टोन (जिन्होंने इस टुकड़े पर प्रतिक्रिया प्रदान की) ने कहा, "यह क्लासिक है 'क्या आप एप्लिकेशन लॉजिक को डेटाबेस में लाते हैं, या डेटाबेस को एप्लिकेशन लॉजिक में लाते हैं?' फिर से खेलना... इस बार मोनोलिथ को तोड़कर लाया गया।" दशकों तक यह विरोधाभास रहने के बाद, यह स्पष्ट है कि दोनों मॉडल अल्पावधि में बने रहेंगे। यह बहुत कम स्पष्ट है कि लंबे समय तक यही स्थिति बनी रहेगी। 

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

• एसईओ संचालित सामग्री और पीआर वितरण। आज ही प्रवर्धित हो जाओ।
• प्लेटोब्लॉकचैन। Web3 मेटावर्स इंटेलिजेंस। ज्ञान प्रवर्धित। यहां पहुंचें।
• मिंटिंग द फ्यूचर डब्ल्यू एड्रिएन एशले। यहां पहुंचें।
• स्रोत: https://a16z.com/2023/04/14/the-modern-transactional-stack/