प्रॉम्प्ट और संदर्भ
एक ऑर्डर सेवा को एक ही व्यावसायिक ऑपरेशन में एक ऑर्डर बनाना, इन्वेंट्री घटाना और एक लेज़र प्रविष्टि लिखनी होगी। DynamoDB द्वारा कमिट करने के बाद नेटवर्क टाइमआउट हो सकता है, इसलिए क्लाइंट अनुरोध दोबारा भेज सकता है। क्षमता लागत और क्षेत्रीय सीमाओं सहित एटॉमिक राइट्स, शर्तों, इडेम्पोटेंट पुनः प्रयासों और समाधान (reconciliation) को डिज़ाइन करने के लिए TransactWriteItems का उपयोग करें।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप एटॉमिक कमिट, सशर्त विफलता (conditional failure), और नेटवर्क टूटने के बाद एक अज्ञात परिणाम (unknown result) के बीच अंतर करते हैं।
- क्या आप
ClientRequestToken, एक टिकाऊ व्यावसायिक इडेम्पोटेंसी कुंजी (business idempotency key), और शर्त अभिव्यक्तियों (condition expressions) का सही ढंग से उपयोग करते हैं। - क्या आप अतिरिक्त ट्रांजैक्शनल क्षमता, API सीमाओं और हॉट-की विवाद (hot-key contention) का ध्यान रखते हैं।
- क्या पुनः प्रयास, क्षतिपूर्ति (compensation), समाधान, मेट्रिक्स और क्रॉस-रीजन निरंतरता (consistency) एक संपूर्ण डिज़ाइन बनाते हैं।
स्पष्टीकरण हेतु प्रश्न
- क्या ऑर्डर, इन्वेंट्री और लेज़र टेबल समान AWS Region और खाता सीमा के अंतर्गत हैं?
- क्या ओवरसेलिंग की अनुमति है, और क्या लेज़र को एक अपरिवर्तनीय केवल-जोड़ने योग्य (append-only) रिकॉर्ड होना चाहिए?
- क्या क्लाइंट टाइमआउट के बाद व्यावसायिक इडेम्पोटेंसी कुंजी द्वारा अंतिम स्थिति के लिए क्वेरी कर सकता है?
- क्या टोकन वैधता विंडो समाप्त होने के बाद पुनः प्रयास हो सकता है?
- क्या क्रॉस-रीजन डिजास्टर-रिकवरी राइटिंग आवश्यक है, या एकल-क्षेत्र (single-region) एटॉमिसीटी पर्याप्त है?
30-सेकंड का उत्तर
मैं प्रत्येक व्यावसायिक ऑपरेशन के लिए एक स्थिर इडेम्पोटेंसी कुंजी बनाऊंगा और ऑर्डर बनाने, इन्वेंट्री को सशर्त रूप से घटाने और लेज़र प्रविष्टि को एटॉमिक रूप से लिखने के लिए एक Region में TransactWriteItems का उपयोग करूंगा। अनुरोध में एक ClientRequestToken होता है; टिकाऊ व्यावसायिक स्थिति और शर्तें डुप्लिकेट कटौती को रोकती हैं। टाइमआउट के बाद, पुनः प्रयास करने से पहले व्यावसायिक कुंजी द्वारा पढ़ें। विवादों, सशर्त विफलताओं, क्षमता और अज्ञात परिणामों की निगरानी करें। क्रॉस-रीजन कार्यों के लिए, इवेंट्स और समाधान का उपयोग करें क्योंकि ट्रांजैक्शन की एटॉमिक सीमा क्षेत्रीय होती है।
विस्तृत उत्तर
चरण 1: व्यावसायिक इनवेरिएंट्स (invariants) बताएं
इनवेरिएंट बताएं: एक सफल ऑर्डर इन्वेंट्री को एक बार कम करता है और एक लेज़र प्रविष्टि बनाता है। ऑर्डर और लेज़र रिकॉर्ड के लिए एक operationId का उपयोग करें, और इन्वेंट्री आइटम पर available >= quantity की आवश्यकता रखें। क्लाइंट टाइमस्टैम्प को एकमात्र कुंजी के रूप में उपयोग न करें; पुनः प्रयास और क्लॉक स्क्यू डुप्लिकेट ऑपरेशन्स बना सकते हैं।
चरण 2: ट्रांजैक्शन क्रियाओं को संयोजित करें
एक TransactWriteItems अनुरोध में Put, Update, Delete, और ConditionCheck क्रियाओं को मिलाएं। ऑर्डर Put के लिए एक अनुपस्थित कुंजी की आवश्यकता होती है, इन्वेंट्री Update एक संस्करण या उपलब्ध मात्रा की जांच करता है, और लेज़र Put एक अद्वितीय कुंजी के रूप में operationId का उपयोग करता है। एक ट्रांजैक्शन में एक ही आइटम पर दो बार कार्य न करें, और क्रिया तथा अनुरोध-आकार की सीमाओं का सम्मान करें।
चरण 3: दो इडेम्पोटेंसी परतें बनाएं
ClientRequestToken अपनी वैधता विंडो के दौरान समान ट्रांजैक्शन अनुरोध को सुरक्षित रूप से पुनः प्रयास करने योग्य बनाता है। ऑर्डर और लेज़र में बनी रहने वाली एक व्यावसायिक इडेम्पोटेंसी कुंजी लंबे जीवनचक्र को कवर करती है। दोनों को एक ही ऑपरेशन की पहचान करनी चाहिए; पुनः प्रयास में नई व्यावसायिक कुंजी नहीं बनाई जानी चाहिए। टोकन विंडो के बाद, ट्रांजैक्शन को फिर से बनाने से पहले व्यावसायिक स्थिति पढ़ें।
चरण 4: अज्ञात परिणाम से विफलता को अलग करें
सशर्त विवाद, क्षमता त्रुटियां और सत्यापन विफलताएं आमतौर पर एक कार्रवाई योग्य विफलता पथ प्रदान करती हैं: त्रुटि के अनुसार एक व्यावसायिक त्रुटि लौटाएं या सीमित बैकऑफ के साथ पुनः प्रयास करें। सबमिशन के बाद खोया हुआ कनेक्शन अज्ञात होता है; तुरंत इन्वेंट्री को वापस न बदलें (reverse न करें)। operationId द्वारा ऑर्डर, इन्वेंट्री संस्करण और लेज़र पढ़ें, फिर स्टेट मशीन को पुनः प्रयास या समाधान चुनने दें।
चरण 5: लागत और हॉट कीज़ का हिसाब रखें
DynamoDB ट्रांजैक्शन तैयारी और कमिट के लिए अंतर्निहित रीड्स या राइट्स करता है, इसलिए क्षमता का उपयोग एकल सामान्य राइट की तुलना में अधिक होता है। आइटम के आकार, समवर्तीता (concurrency) और पुनः प्रयास प्रवर्धन (retry amplification) से थ्रूपुट का अनुमान लगाएं, और हॉट इन्वेंट्री को शार्ड करें या आरक्षण कतार (reservation queue) का उपयोग करें। औसत WCU अपर्याप्त है; सशर्त विफलताएं और विवाद भी विलंबता और क्षमता बजट की खपत करते हैं।
चरण 6: क्षेत्रीय आवश्यकताओं को संभालें
ट्रांजैक्शन की एटॉमिसीटी कॉलिंग Region में ट्रांजैक्शन सीमा पर लागू होती है। यदि एनालिटिक्स या कोई प्रतिकृति (replica) कहीं और रहती है, तो operationId युक्त एक इवेंट प्रकाशित करें; उपभोक्ता इडेम्पोटेंट रूप से लिखते हैं और समाधान अंतराल या डुप्लिकेट ढूंढता है। प्रतिकृति अंतराल (replication lag) के दौरान, एक रिमोट रीड मॉडल तत्काल ट्रांजैक्शन कमिट का प्रमाण नहीं है।
चरण 7: निरीक्षण और पुनर्प्राप्ति करें
ट्रांजैक्शन की सफलता, सशर्त विफलताएं, विवाद, थ्रॉटलिंग, पुनः प्रयास गणना, अज्ञात परिणाम, प्रति-टेबल क्षमता और एंड-टू-एंड विलंबता रिकॉर्ड करें। PENDING, COMMITTED, RECONCILING, और FAILED जैसी स्थितियों का उपयोग करें; एक स्कैनर अज्ञात स्थितियों को संभालता है और या तो लेज़र को पूरा करता है या एक मानव समीक्षा कतार बनाता है। operationId द्वारा अनुरोध लॉग, टेबल आइटम और इवेंट्स को सहसंबंधित करें।
मॉडल उत्तर
प्रत्येक ऑर्डर के लिए मैं एक स्थिर operationId बनाऊंगा और ऑर्डर बनाने, इन्वेंट्री को सशर्त रूप से घटाने और उस ID द्वारा कीड (keyed) किए गए लेज़र आइटम को लिखने के लिए एक Region में TransactWriteItems का उपयोग करूंगा। ऑर्डर के लिए अनुपस्थित कुंजी आवश्यक है, इन्वेंट्री इसके संस्करण और available >= quantity की जांच करती है, और लेज़र स्वाभाविक रूप से डुप्लिकेट-मुक्त रहता है। अनुरोध में एक स्थिर ClientRequestToken भी होता है। एक सशर्त विफलता एक व्याख्या योग्य व्यावसायिक त्रुटि लौटाती है; कमिट के बाद का टाइमआउट इन्वेंट्री को आँख मूंदकर उलटने के बजाय पहले operationId द्वारा तीनों रिकॉर्ड पढ़ता है। क्षमता के अनुमान में ट्रांजैक्शनल तैयारी और कमिट कार्य, हॉट कीज़ और पुनः प्रयास प्रवर्धन शामिल हैं। क्रॉस-रीजन प्रसार क्रॉस-रीजन एटॉमिसीटी का दावा करने के बजाय इडेम्पोटेंट इवेंट्स और समाधान का उपयोग करता है। मेट्रिक्स में विवाद, क्षमता, अज्ञात परिणाम और स्टेट-मशीन पुनर्प्राप्ति समय शामिल हैं।
सामान्य गलतियाँ
- टाइमआउट को इस बात का प्रमाण मानना कि ट्रांजैक्शन विफल हो गया और तुरंत इन्वेंट्री को वापस बदलना।
- प्रत्येक पुनः प्रयास पर एक नई व्यावसायिक कुंजी उत्पन्न करना, जिससे डुप्लिकेट ऑर्डर या लेज़र प्रविष्टियाँ बन जाएं।
- केवल
ClientRequestTokenपर निर्भर रहना और टिकाऊ व्यावसायिक इडेम्पोटेंसी को छोड़ देना। - सशर्त विवादों, ट्रांजैक्शन सीमाओं और अतिरिक्त ट्रांजैक्शनल क्षमता को अनदेखा करना।
- ग्लोबल-टेबल प्रतिकृति या रिमोट रीड को ट्रांजैक्शन कमिट का प्रमाण मानना।
- मैन्युअल लॉग निरीक्षण के अलावा कोई अज्ञात-स्थिति स्कैनर या समाधान पथ न होना।
अनुवर्ती प्रश्न
अनुवर्ती 1: क्या ClientRequestToken स्थायी इडेम्पोटेंसी की गारंटी देता है?
नहीं। यह केवल API-परिभाषित वैधता विंडो को कवर करता है। दीर्घकालिक इडेम्पोटेंसी के लिए ऑर्डर, लेज़र या ऑपरेशन टेबल में एक व्यावसायिक कुंजी और अंतिम स्थिति की आवश्यकता होती है।
अनुवर्ती 2: क्या इन्वेंट्री स्थिति की विफलता का पुनः प्रयास किया जाना चाहिए?
यदि इन्वेंट्री अपर्याप्त है, तो पुनः प्रयास करने से परिणाम नहीं बदल सकता है और एक व्यावसायिक विफलता लौटाई जानी चाहिए। एक क्षणिक विवाद या थ्रॉटल को बैकऑफ, समान ऑपरेशन कुंजी और सीमित प्रयास गणना के साथ पुनः प्रयास किया जा सकता है।
अनुवर्ती 3: आप टाइमआउट के बाद परिणाम कैसे तय करते हैं?
operationId द्वारा ऑर्डर, इन्वेंट्री संस्करण और लेज़र पढ़ें। सुसंगत रिकॉर्ड कमिट का संकेत देते हैं; आंशिक दृश्यता या असहमति RECONCILING में प्रवेश करती है, जहां एक वर्कफ़्लो पूर्णता या मानव प्रबंधन का चयन करता है।
अनुवर्ती 4: क्रॉस-रीजन राइट्स को एक ट्रांजैक्शन में क्यों नहीं रखा जाता?
API कई Regions में एटॉमिसीटी का विस्तार नहीं करता है। इवेंचुअल-कंसिस्टेंसी विंडो और डिग्रेडेशन व्यवहार का दस्तावेजीकरण करते हुए इवेंट्स, इडेम्पोटेंट उपभोक्ताओं और समाधान का उपयोग करें।
अनुवर्ती 5: आप ट्रांजैक्शन विवादों का पता कैसे लगाते हैं?
operationId, आइटम कीज़, शर्त संस्करण और पुनः प्रयास गणना को लॉग करें, फिर हॉट की द्वारा विवादों को एकत्रित करें। लगातार विवादित इन्वेंट्री आइटम को शार्डिंग, आरक्षण या कतार-आधारित आवंटन की आवश्यकता हो सकती है।
अनुवर्ती 6: आप अज्ञात-परिणाम पथ का परीक्षण कैसे करते हैं?
क्लाइंट टाइमआउट का अनुकरण करने के लिए सर्वर द्वारा कमिट की पुष्टि करने के बाद प्रतिक्रिया छोड़ दें (drop कर दें)। लुकअप, पुनः प्रयास, स्थिति संक्रमण, इवेंट डिडुप्लीकेशन और समाधान को सत्यापित करें ताकि इन्वेंट्री और लेज़र कभी भी दो बार लागू न हों।