प्रॉम्प्ट और संदर्भ
एक ऑर्डर, प्रेफरेंस या इन्वेंट्री सर्विस को कई Regions में स्थानीय रीड्स और राइट्स प्रदान करने चाहिए। DynamoDB Global Tables के MREC (मल्टी-Region इवेंचुअल कंसिस्टेंसी) और MRSC (मल्टी-Region स्ट्रॉन्ग कंसिस्टेंसी) की तुलना करें, और रूटिंग, कॉन्फ्लिक्ट्स, फेलओवर, कैपेसिटी और रिकवरी की व्याख्या करें। यह इंटरव्यू कंसिस्टेंसी और परिचालन सीमाओं का परीक्षण करता है, न कि केवल डेटाबेस को किसी अन्य स्थान पर कॉपी करने का।
Global Tables प्रबंधित मल्टी-Region, मल्टी-एक्टिव रेप्लिकेशन हैं: कोई भी रेप्लिकेट रीड्स और राइट्स को पूरा कर सकता है। MREC डिफ़ॉल्ट है और एसिंक्रोनस रूप से रेप्लिकेट करता है; जब एक ही आइटम को अलग-अलग Regions में लगभग एक साथ संशोधित किया जाता है, तो DynamoDB इसे आंतरिक टाइमस्टैम्प लास्ट-राइटर-विन्स (LWW) नियम के साथ आइटम स्तर पर हल करता है। MRSC किसी राइट को स्वीकार (acknowledge) करने से पहले कम से कम एक अन्य Region में सिंक्रोनस रूप से रेप्लिकेट करता है, और किसी भी रेप्लिकेट पर स्ट्रॉन्गली कंसिस्टेंट रीड्स नवीनतम वैल्यू लौटाते हैं; इसके लिए ठीक तीन Regions (तीन रेप्लिकेट्स, या दो रेप्लिकेट्स प्लस एक विटनेस) की आवश्यकता होती है।
इंटरव्यूअर क्या टेस्ट कर रहा है
एक बेहतरीन उत्तर RPO, राइट लेटेंसी और रीड गारंटी से मोड चुनने से पहले व्यावसायिक इनवेरिएंट्स (business invariants) को आइटम्स, पार्टीशन कीज़ और क्रॉस-आइटम ट्रांजैक्शन्स में विभाजित करता है। लास्ट-राइटर-विन्स के तहत साइलेंट डेटा लॉस, MRSC की तीन-Region की बाध्यता, Regions में MREC ट्रांजैक्शन्स की विजिबिलिटी और फेलबैक के दौरान ऑर्डरिंग के बारे में प्रश्नों की अपेक्षा करें।
केवल यह कहना कि “मल्टी-Region रेप्लिकेशन सक्षम करें” पर्याप्त नहीं है। स्थानीय Region एंडपॉइंट्स, एक आइटम पर डुअल राइट्स से कैसे बचें, ReplicationLatency की निगरानी कैसे करें, और डिलीट्स, रीप्रयासों (retries) और डुप्लिकेट इवेंट्स को कैसे संभालें, इसकी व्याख्या करें।
पहले स्पष्ट करने योग्य प्रश्न
इनवेरिएंट्स और कॉन्फ्लिक्ट का स्वरूप
पूछें कि क्या ऑर्डर की स्थितियाँ पीछे जा सकती हैं, क्या इन्वेंट्री लीनियरिज़ेबल होनी चाहिए, और क्या एक आइटम को कई Regions में एक साथ एडिट किया जा सकता है। स्वतंत्र रूप से मर्ज होने योग्य फ़ील्ड्स अलग-अलग आइटम्स या वर्ज़न्ड सब-रिकॉर्ड्स हो सकते हैं। क्रॉस-फ़ील्ड एटॉमिसीटी के लिए यह समझना आवश्यक है कि MREC ट्रांजैक्शन्स केवल इनवोकिंग Region में एटॉमिक होते हैं और एक ट्रांजैक्शन के रूप में रेप्लिकेट नहीं होते हैं।
RPO, लेटेंसी और Region की संख्या
RPO, P99 राइट लेटेंसी, फेलओवर समय और कम्प्लायंट Regions को स्पष्ट करें। MREC उपलब्ध Regions की किसी भी संख्या का उपयोग कर सकता है और आमतौर पर एक सेकंड के भीतर प्रचारित (propagate) होता है; MRSC तीन Regions की आवश्यकता के साथ-साथ क्रॉस-Region स्ट्रॉन्ग रीड्स और ज़ीरो-RPO लक्ष्य के लिए कुछ राइट लेटेंसी का समझौता करता है।
राइट ओनरशिप और रिकवरी
तय करें कि क्या राइट्स वास्तव में मल्टी-एक्टिव हैं या प्रत्येक टेनेंट का एक होम Region है जिसके रीड रेप्लिकेट्स अन्य जगहों पर हैं। यदि व्यवसाय LWW को स्वीकार नहीं कर सकता है, तो राइटर्स को सीमित करने के लिए IAM या रूटिंग का उपयोग करें और सेमांटिक्स को रेप्लिकेशन पर छोड़ने के बजाय रिकवरी के दौरान कॉन्फ्लिक्ट निर्णयों के लिए प्राधिकारी (authority) को परिभाषित करें।
30-सेकंड का उत्तर
“मैं व्यावसायिक इनवेरिएंट्स के आधार पर मोड चुनता हूँ: इन्वेंट्री डिक्रिमेंट्स और क्रॉस-Region स्ट्रॉन्ग रीड्स MRSC की ओर संकेत करते हैं, जबकि वे वर्कलोड्स जो संक्षिप्त बासीपन (staleness) को सहन करते हैं और स्थानीय राइट लेटेंसी को प्राथमिकता देते हैं, डिफ़ॉल्ट MREC का उपयोग करते हैं। MREC एसिंक्रोनस और आइटम-लेवल LWW है, इसलिए मैं प्रत्येक ऑर्डर या टेनेंट को एक Region में होम करता हूँ और कंडीशनल राइट्स, आइडेम्पोटेंसी कीज़ और स्पष्ट वर्ज़न्स जोड़ता हूँ; नॉन-मर्ज करने योग्य स्थितियाँ LWW पर निर्भर नहीं करती हैं। प्रत्येक अनुरोध अपने स्थानीय एंडपॉइंट का उपयोग करता है, और एक क्षेत्रीय विफलता के दौरान ट्रैफ़िक एप्लिकेशन एज पर स्थानांतरित हो जाता है। मैं ReplicationLatency, रेप्लिकेशन एरर्स और कंडीशनल-राइट विफलताओं की निगरानी करता हूँ, फिर वर्ज़न्स, इवेंट्स और व्यावसायिक नियमों का उपयोग करके रिकवरी को रीप्ले और ऑडिट करता हूँ।”
स्टेप-बाय-स्टेप समाधान
स्टेप 1: कंसिस्टेंसी मोड चुनें
MREC डिफ़ॉल्ट है, किसी भी संख्या में Regions का समर्थन करता है, और इवेंचुअली कंसिस्टेंट है, जो प्राथमिकताओं (preferences), कैटलॉग्स और स्टेल-टॉलरेंट रीड मॉडल्स के लिए उपयुक्त है। MRSC सफलता से पहले कम से कम एक अन्य Region में एक राइट को सिंक्रोनस रूप से रेप्लिकेट करता है; किसी भी रेप्लिकेट पर स्ट्रॉन्ग रीड्स नवीनतम वैल्यू देखते हैं। इसके लिए ठीक तीन Regions की आवश्यकता होती है और यह ट्रांजैक्शन ऑपरेशन्स का समर्थन नहीं करता है। मोड को निर्माण के समय चुना जाता है: रेप्लिकेट्स मोड्स को मिक्स नहीं कर सकते हैं और टेबल को बाद में बदला नहीं जा सकता है।
स्टेप 2: राइट टोपोलॉजी को परिभाषित करें
एप्लिकेशन्स को अपने स्थानीय Region में DynamoDB एंडपॉइंट का उपयोग करना चाहिए। मल्टी-एक्टिव राइट्स केवल तभी उपयुक्त होते हैं जब व्यवसाय समवर्ती कॉन्फ्लिक्ट्स को हल कर सकता है। ऑर्डर्स और इन्वेंट्री जैसे अत्यधिक बाध्यकारी ऑब्जेक्ट्स अन्य स्थानों पर रीड्स के साथ होम-Region राइट्स का उपयोग कर सकते हैं, या टेनेंट या ऑर्डर द्वारा सिंगल-राइटर पार्टीशन्स का उपयोग कर सकते हैं। क्रॉस-Region कॉल्स लेटेंसी और विफलता की संभावना को बढ़ाते हैं; ट्रैफ़िक स्विचिंग एप्लिकेशन एंट्री पॉइंट या रूटिंग लेयर का हिस्सा है।
स्टेप 3: MREC के तहत कॉन्फ्लिक्ट्स को नियंत्रित करें
MREC एक आइटम के लगभग समवर्ती अपडेट्स के लिए आंतरिक-टाइमस्टैम्प LWW का उपयोग करता है। रेप्लिकेट्स कन्वर्ज होते हैं, लेकिन खारिज किए गए व्यावसायिक परिवर्तन स्वचालित रूप से क्षतिपूर्ति (compensation) कार्य नहीं बनते हैं। वर्ज़न्स के लिए कंडीशन एक्सप्रेशन्स का उपयोग करें और एक आइडेम्पोटेंट रिक्वेस्ट ID शामिल करें। नॉन-ओवरराइटेबल स्थितियों के लिए केवल अपेंड-ओनली (append-only) इवेंट्स या कॉन्फ्लिक्ट रिकॉर्ड्स को सुरक्षित रखें। डिलीट्स को एक स्पष्ट टॉम्बस्टोन या स्थिति के साथ दर्शाएं ताकि कोई पुराना अपडेट हटाए गए ऑब्जेक्ट को पुनर्जीवित न कर सके।
स्टेप 4: ट्रांजैक्शन्स और रीप्रयासों को संभालें
MREC TransactWriteItems केवल इनवोकिंग Region में एटॉमिक है; अन्य रेप्लिकेट्स अस्थायी रूप से आंशिक प्रभावों का निरीक्षण कर सकते हैं, इसलिए क्रॉस-Region रीड कोई ट्रांजैक्शन पुष्टि नहीं है। रीप्रयासों को बाउंडेड एक्सपोनेंशियल बैकऑफ़ और आइडेम्पोटेंसी कीज़ के साथ कंडीशनल विफलताओं, थ्रॉटलिंग और रेप्लिकेशन विलंब में अंतर करना चाहिए। MRSC ट्रांजैक्शन ऑपरेशन्स का समर्थन नहीं करता है, इसलिए क्रॉस-आइटम इनवेरिएंट्स को एक नए मॉडल या सर्विस कोऑर्डिनेशन की आवश्यकता होती है।
स्टेप 5: फेलओवर और रिकवरी की योजना बनाएं
रेप्लिकेशन लेटेंसी, रेप्लिकेशन एरर्स, कंडीशनल-राइट विफलताओं, रिक्वेस्ट Region और व्यावसायिक वर्ज़न्स की निगरानी करें। आइसोलेशन के दौरान, एंट्री ट्रैफ़िक को एक स्वस्थ Region में ले जाएं। MREC के साथ, पहले कॉन्फ्लिक्ट-संवेदनशील राइट्स को रोकें या टेनेंट्स को फिर से होम करें, कटओवर समय और अंतिम दृश्य वर्ज़न को रिकॉर्ड करें। रिकवरी के बाद, इवेंट लॉग्स, वर्ज़न्स और व्यावसायिक नियमों के साथ कन्वर्जेंस को मान्य करें; केवल समान रेप्लिकेट्स ही एक सही इन्वेंट्री या ऑर्डर साबित नहीं करते हैं।
स्टेप 6: कैपेसिटी, सुरक्षा और गवर्नेंस
प्रत्येक रेप्लिकेट के लिए रीड/राइट कैपेसिटी, ऑटो स्केलिंग और कोटा का आकलन करें। एक नया रेप्लिकेट निर्माण के समय सोर्स-Region कैपेसिटी सेटिंग्स को इनहेरिट करता है और बाद में इसे एडजस्ट किया जा सकता है। प्रति रेप्लिकेट डिलीशन प्रोटेक्शन सक्षम करें, राइटर Regions और टेबल ऑपरेशन्स को प्रतिबंधित करने के लिए IAM का उपयोग करें, और याद रखें कि KMS अनुमतियों के खो जाने पर संबंधित रेप्लिकेशन रुक जाता है। मल्टी-अकाउंट Global Tables MREC का समर्थन करते हैं, MRSC का नहीं, इसलिए अकाउंट, Region और ऑडिट ओनरशिप स्पष्ट होनी चाहिए।
स्टेप 7: सत्यापन और अभ्यास (Rehearse)
दो Regions में एक ही आइटम पर समवर्ती राइट्स, कंडीशनल रीप्रयासों, पार्टीशन्स, देर से अपडेट के साथ डिलीट्स, रेप्लिकेशन स्पाइक्स, ट्रैफ़िक कटओवर और फेलबैक का अभ्यास करें। इवेंचुअल कन्वर्जेंस, पूर्ण क्षतिपूर्ति इवेंट्स और डुप्लिकेट-सुरक्षित रीप्ले को सत्यापित करें, साथ ही ReplicationLatency और कॉन्फ्लिक्ट काउंट्स को रिक्वेस्ट IDs से सहसंबद्ध (correlate) करें। लोड टेस्ट्स को वास्तविक Region दूरियों और कैपेसिटी मोड्स को प्रतिबिंबित करना चाहिए; सिंगल-मशीन लेटेंसी क्रॉस-Region का अनुमान नहीं है।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं इनवेरिएंट्स के आधार पर मोड चुनता हूँ। महत्वपूर्ण डेटा जिसके लिए क्रॉस-Region स्ट्रॉन्ग रीड्स और ज़ीरो-RPO लक्ष्य की आवश्यकता होती है, वह MRSC का उपयोग कर सकता है, जिसमें ठीक तीन Regions, उच्च राइट लेटेंसी और कोई ट्रांजैक्शन ऑपरेशन न होना स्वीकार किया जाता है। कैटलॉग्स और प्राथमिकताओं के लिए MREC का उपयोग किया जा सकता है। चूँकि एसिंक्रोनस आइटम-लेवल LWW व्यावसायिक सेमांटिक्स को मर्ज नहीं कर सकता है, ऑर्डर्स और इन्वेंट्री टेनेंट या ऑर्डर होम-Region सिंगल राइट्स, कंडीशन एक्सप्रेशन्स, वर्ज़न्स और आइडेम्पोटेंसी कीज़ का उपयोग करते हैं। मर्ज करने योग्य फ़ील्ड्स अलग-अलग आइटम्स हैं; नॉन-मर्ज करने योग्य अपडेट्स कॉन्फ्लिक्ट इवेंट्स बन जाते हैं।
एप्लिकेशन स्थानीय एंडपॉइंट्स का उपयोग करता है और एंट्री लेयर क्षेत्रीय फेलओवर करती है। मैं थ्रॉटलिंग और विलंब के लिए बाउंडेड बैकऑफ़ के साथ ReplicationLatency, रेप्लिकेशन और कंडीशनल-राइट विफलताओं, और वर्ज़न अंतरों की निगरानी करता हूँ। रिकवरी के दौरान मैं प्रभावित राइट्स को फ़्रीज़ करता हूँ, इवेंट लॉग्स और व्यावसायिक नियमों से कन्वर्जेंस को मान्य करता हूँ, और फिर धीरे-धीरे ट्रैफ़िक को फिर से खोलता हूँ। मैं प्रति रेप्लिकेट कैपेसिटी, डिलीशन प्रोटेक्शन, IAM और KMS का ऑडिट करता हूँ और समवर्ती राइट्स, पार्टीशन्स, लेट डिलीट्स और डुप्लिकेट रीप्ले का अभ्यास करता हूँ।
सामान्य गलतियाँ
- गलती: यह मान लेना कि Global Tables का अर्थ अप्रतिबंधित मल्टी-एक्टिव राइट्स है। → यह क्यों विफल होता है: MREC LWW नॉन-मर्ज करने योग्य व्यावसायिक परिवर्तनों को हटा सकता है। → सुधार: राइट ओनरशिप असाइन करें या स्पष्ट वर्ज़न्स, इवेंट्स और क्षतिपूर्ति डिज़ाइन करें।
- गलती: MREC ट्रांजैक्शन्स को ग्लोबली एटॉमिक मानना। → यह क्यों विफल होता है: एटॉमिसीटी इनवोकिंग Region के लिए स्थानीय होती है और अन्य रेप्लिकेट्स आंशिक प्रभाव देख सकते हैं। → सुधार: क्रॉस-Region इनवेरिएंट्स को फिर से मॉडल करें और इवेंट्स और आइडेम्पोटेंसी के साथ समन्वय करें।
- गलती: टाइमआउट के बाद आँख मूंदकर Regions बदलना। → यह क्यों विफल होता है: डुअल राइट्स कॉन्फ्लिक्ट्स और फेलबैक जोखिम को बढ़ाते हैं। → सुधार: राइट्स को रोकें या सीमित करें, वर्ज़न्स रिकॉर्ड करें, फिर टेनेंट या व्यावसायिक सीमाओं के साथ स्विच करें।
- गलती: रेप्लिकेट कन्वर्जेंस को सही इन्वेंट्री के समान मानना। → यह क्यों विफल होता है: LWW रेप्लिकेशन को हल करता है, व्यावसायिक अर्थ को नहीं। → सुधार: कंडीशनल राइट्स, इवेंट लॉग्स, क्षतिपूर्ति और ऑडिट के साथ सत्यापन करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: आप MRSC कब चुनेंगे?
MRSC तब चुनें जब क्रॉस-Region स्ट्रॉन्ग रीड्स और ज़ीरो-RPO लक्ष्य राइट लेटेंसी और Region लचीलेपन से अधिक महत्वपूर्ण हों। इसके लिए ठीक तीन Regions, वैकल्पिक रूप से एक विटनेस की आवश्यकता होती है, और यह ट्रांजैक्शन्स का समर्थन नहीं करता है। यदि वर्कलोड को मनमाने रेप्लिकेट काउंट्स या मल्टी-अकाउंट रेप्लिकेशन की आवश्यकता है, तो MREC और सर्विस-लेवल समन्वय का पुनर्मूल्यांकन करें।
फॉलो-अप 2: क्या होगा यदि LWW किसी इन्वेंट्री डिक्रिमेंट को ओवरराइट कर दे?
LWW से मात्रा को पुनर्प्राप्त (recover) न करें। डिक्रिमेंट के लिए कंडीशन एक्सप्रेशन और वर्ज़न का उपयोग करें, प्रोडक्ट या इन्वेंट्री शार्ड द्वारा एक स्थिर राइट ओनर असाइन करें, और प्रत्येक डिक्रिमेंट को एक आइडेम्पोटेंट इवेंट के रूप में रिकॉर्ड करें। एक कॉन्फ्लिक्ट डिटेक्टर इवेंट अनुक्रमों की तुलना करता है और क्षतिपूर्ति या एक मानव समीक्षा कतार जारी करता है; रीड्स वर्ज़न और दृश्यता समय दोनों की जांच करते हैं।
फॉलो-अप 3: जब MREC रेप्लिकेशन लैग बढ़ जाता है तो आप क्या करते हैं?
अलर्ट्स को सोर्स Region, डेस्टिनेशन Region और व्यावसायिक प्रभाव के आधार पर समूहीकृत करें। कॉन्फ्लिक्ट्स पैदा करने से रोकने के लिए क्रॉस-Region राइट्स को सीमित करें या टेनेंट्स को उनके होम Region में वापस लौटाएं। क्लाइंट रीप्रयासों को सीमित करें, फिर मल्टी-एक्टिव राइट्स को पुनर्स्थापित करने से पहले वर्ज़न्स, लेट इवेंट्स और डिलीट मार्कर्स का मिलान (reconcile) करें। ReplicationLatency प्रचार को मापता है, व्यावसायिक शुद्धता को नहीं।
फॉलो-अप 4: आप फेलबैक का परीक्षण कैसे करते हैं?
ट्रैफ़िक कटओवर, पुराने Region की रिकवरी, दोनों तरफ आने वाले अनुरोधों और लेट डिलीट्स का अभ्यास करें। प्रत्येक अनुरोध के लिए Region, वर्ज़न और आइडेम्पोटेंसी ID रिकॉर्ड करें। सत्यापित करें कि पुराना Region नए स्टेट को ओवरराइट नहीं कर सकता है, कॉन्फ्लिक्ट इवेंट्स ट्रैसेबल बने रहते हैं, और क्षतिपूर्ति दोहराने योग्य है। RPO, RTO, कॉन्फ्लिक्ट काउंट और मानवीय हस्तक्षेप की रिपोर्ट करें।
फॉलो-अप 5: रेप्लिकेट्स MREC और MRSC को मिक्स क्यों नहीं कर सकते?
कंसिस्टेंसी मोड निर्माण के समय टेबल-स्तरीय सेटिंग है: रेप्लिकेट्स अलग-अलग मोड्स का उपयोग नहीं कर सकते हैं और निर्माण के बाद टेबल को स्विच नहीं किया जा सकता है। बदली हुई आवश्यकता के लिए एक नई टेबल, माइग्रेशन, और एक नियंत्रित डुअल-राइट या रीप्ले विंडो की आवश्यकता होती है, जिसमें कैपेसिटी, अनुमतियाँ, क्लाइंट अनुकूलता और रोलबैक को पहले मान्य किया जाता है।