प्रॉम्प्ट और संदर्भ
यह प्रश्न बैकएंड, प्लेटफ़ॉर्म और डिस्ट्रीब्यूटेड-सिस्टम इंटरव्यू के लिए उपयुक्त है। साक्षात्कारकर्ता सीमा को समझना चाहता है: SQS डुप्लीकेशन अंतराल के भीतर समान डिडुप्लीकेशन आईडी को डुप्लिकेट मानता है और संदेश प्राप्त होने और डिलीट होने के बाद भी उस आईडी को ट्रैक करना जारी रखता है; यह किसी बाहरी डेटाबेस, भुगतान या ईमेल साइड इफेक्ट को स्वाभाविक रूप से exactly-once नहीं बनाता है।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
एक मजबूत उत्तर निर्माता (producer) डुप्लीकेशन, FIFO ऑर्डरिंग, उपभोक्ता दृश्यता टाइमआउट (visibility timeout), विलोपन पावती (deletion acknowledgement), और व्यावसायिक आइडम्पोटेंसी को अलग करता है। AWS डिडुप्लीकेशन आईडी को एक ऐसे टोकन के रूप में परिभाषित करता है जो डुप्लिकेट डिलीवरी को रोकता है; जब सामग्री-आधारित डुप्लीकेशन (content-based deduplication) सक्षम हो और कोई आईडी न दी गई हो, तो SQS संदेश बॉडी को हैश करके एक आईडी प्राप्त कर सकता है। उत्तर में केवल “FIFO कभी डुप्लिकेट नहीं करता” कहने के बजाय अंतराल, पुनः प्रयास (retries) और अवलोकनीयता (observability) को शामिल किया जाना चाहिए।
पहले पूछने योग्य स्पष्टीकरण प्रश्न
सिमेंटिक सीमा
पूछें कि क्या आवश्यकता कतार-स्तरीय (queue-level) डुप्लिकेट दमन, कम से कम एक बार (at-least-once) प्रोसेसिंग, या एक बार का व्यावसायिक प्रभाव है। "एक संदेश" को "एक शुल्क (charge)" से अलग रखें।
डिडुप्लीकेशन इनपुट
पुष्टि करें कि क्या निर्माता एक स्थिर MessageDeduplicationId बनाता है, क्या सामग्री-आधारित डिडुप्लीकेशन सक्षम है, संदेश समूहों को कैसे चुना जाता है, और क्या पुनः प्रयास पांच मिनट के अंतराल के भीतर होते हैं।
विफलता बिंदु
प्राप्ति (receive), प्रोसेसिंग, साइड-इफेक्ट लेखन और DeleteMessage की समयरेखा बनाएं। पूछें कि उपभोक्ता क्रैश, विजिबिलिटी टाइमआउट, नेटवर्क पुनः प्रयास और डाउनस्ट्रीम टाइमआउट पर क्या होता है।
30-सेकंड उत्तर ढांचा
“FIFO डिडुप्लीकेशन आईडी पांच मिनट के अंतराल के दौरान उसी संदेश को दोबारा स्वीकार किए जाने से रोकता है और उस आईडी को ट्रैक करना जारी रखता है; यह कतार-स्तरीय डुप्लिकेट भेजने और ऑर्डरिंग को संभालता है, न कि exactly-once बाहरी दुष्प्रभावों को। मैं एक आइडम्पोटेंसी रिकॉर्ड के लिए एक स्थिर व्यावसायिक कुंजी (business key) का उपयोग करूंगा, साइड-इफेक्ट स्थिति और एक आउटबॉक्स को एक ही लेनदेन (transaction) या किसी अन्य पुनः प्रयास-सुरक्षित सीमा में रखूंगा, और सफलता के बाद ही संदेश को हटाऊंगा। क्रैश के कारण पुनः डिलीवरी हो सकती है, लेकिन दोहराया गया प्रयास पूर्ण किए गए रिकॉर्ड को पढ़ लेगा।”
चरण-दर-चरण विस्तृत उत्तर
चरण 1: परीक्षण योग्य गारंटी बताएं
बताएं कि पांच मिनट के डुप्लीकेशन अंतराल के दौरान समान डिडुप्लीकेशन आईडी को डुप्लिकेट माना जाता है; SQS प्राप्त करने और हटाने के बाद भी आईडी को ट्रैक करना जारी रखता है। अंतराल को स्थायी डुप्लीकेशन के रूप में वर्णित न करें।
चरण 2: निर्माता और उपभोक्ता नियंत्रणों को अलग करें
निर्माता एक व्यावसायिक कमांड के लिए एक स्थिर आईडी का उपयोग करता है; सामग्री हैशिंग केवल तभी काम करती है जब बॉडी पूरी तरह से उस कमांड का प्रतिनिधित्व करती है। उपभोक्ता को ऑर्डर, भुगतान इंटेंट, या कमांड आईडी पर एक स्थायी अद्वितीय बाधा (unique constraint) की आवश्यकता होती है क्योंकि अंतराल के बाद किया गया पुनः प्रयास अभी भी वही व्यावसायिक क्रिया हो सकता है।
चरण 3: क्रैश विंडो को कवर करें
यदि उपभोक्ता डेटाबेस में लिखता है और फिर क्रैश हो जाता है, तो संदेश अपने विजिबिलिटी टाइमआउट के बाद फिर से प्रकट हो सकता है। साइड-इफेक्ट स्थिति और आइडम्पोटेंसी कुंजी को एक ही लेनदेन में रखें, या पुनः चलाने योग्य प्रकाशन (replayable publication) के लिए एक आउटबॉक्स का उपयोग करें; सफल कमिट के बाद ही डिलीट करें।
चरण 4: ऑर्डरिंग और पॉइज़न संदेशों को संभालें
जब क्रम महत्वपूर्ण हो तो उसी MessageGroupId का उपयोग करें और कार्य के अनुरूप विजिबिलिटी टाइमआउट सेट करें। बार-बार विफल होने वाले संदेशों को मूल आईडी, प्राप्ति संख्या (receive count), और विफलता के कारण के साथ एक डेड-लेटर कतार (DLQ) में ले जाएं ताकि पुनः प्रयास समूह को हमेशा के लिए ब्लॉक न करें।
चरण 5: सत्यापित करें और निरीक्षण करें
निर्माता के पुनः प्रयासों, लिखने के बाद उपभोक्ता क्रैश, DeleteMessage टाइमआउट, और अंतराल के बाहर रीप्ले का परीक्षण करें। डुप्लिकेट व्यावसायिक कुंजियों, ApproximateReceiveCount, DLQ गहराई, विजिबिलिटी टाइमआउट और एंड-टू-एंड विलंबता की निगरानी करें; अलर्ट को कतार के डुप्लिकेट और व्यावसायिक डुप्लिकेट के बीच अंतर करना चाहिए।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं SQS के पांच मिनट के डुप्लीकेशन को एक ट्रांसपोर्ट सुरक्षा उपाय के रूप में मानता हूं, न कि एक बार के भुगतान की गारंटी के रूप में। निर्माता प्रत्येक भुगतान इंटेंट के लिए एक स्थिर कमांड आईडी बनाता है और पुनः प्रयास पर इसका पुन: उपयोग करता है। उपभोक्ता पहले इनबॉक्स तालिका में एक अद्वितीय कमांड आईडी लागू करता है, फिर उसी लेनदेन में ऑर्डर की स्थिति और एक आउटबॉक्स इवेंट लिखता है, और कमिट के बाद संदेश को हटा देता है। यदि प्रक्रिया लिखने के बाद क्रैश हो जाती है, तो पुनः डिलीवरी पूर्ण रिकॉर्ड को ढूंढती है और दोबारा शुल्क नहीं लेती है। मैं डुप्लिकेट कमांड, प्राप्ति संख्या और DLQ की निगरानी करूंगा, और इन-विंडो, आउट-ऑफ-विंडो, और DeleteMessage पुनः प्रयासों के दौरान विफलताओं को इंजेक्ट करूंगा।
सामान्य गलतियाँ
- गलती: यह कहना कि FIFO का मतलब स्थायी exactly-once है। → यह क्यों विफल होता है: यह पांच मिनट के अंतराल और उपभोक्ता क्रैश को अनदेखा करता है। → सुधार: आईडी की समय सीमा बताएं और व्यावसायिक आइडम्पोटेंसी जोड़ें।
- गलती: प्रत्येक पुनः प्रयास के लिए एक नई डिडुप्लीकेशन आईडी बनाना। → यह क्यों विफल होता है: एक कमांड कई संदेश बन जाती है। → सुधार: एक स्थिर कमांड आईडी का पुन: उपयोग करें।
- गलती: प्रोसेसिंग पूरी होने से पहले डिलीट करना। → यह क्यों विफल होता है: डाउनस्ट्रीम विफलता संदेश के नुकसान में बदल जाती है। → सुधार: सफल कमिट के बाद डिलीट करें और टाइमआउट पर पुनः डिलीवरी की अनुमति दें।
- गलती: केवल बॉडी हैश पर निर्भर रहना। → यह क्यों विफल होता है: टाइमस्टैम्प या अप्रासंगिक फ़ील्ड डुप्लीकेशन को बायपास कर सकते हैं। → सुधार: व्यावसायिक कमांड के लिए एक स्पष्ट स्थिर आईडी परिभाषित करें।
फॉलो-अप और उत्तर
फॉलो-अप 1: क्या होगा यदि वही कमांड पांच मिनट बाद आए?
यह तय करने के लिए कि क्या यह पूरा हो गया है, स्थायी व्यावसायिक आइडम्पोटेंसी रिकॉर्ड का उपयोग करें; कतार डुप्लीकेशन छोटी अवधि के दोहराव को कम करता है लेकिन दीर्घकालिक व्यावसायिक स्थिति की जगह नहीं ले सकता।
फॉलो-अप 2: प्रोसेसिंग से पहले डिलीट क्यों नहीं करते?
पहले डिलीट करने से डाउनस्ट्रीम विफलता संदेश हानि में बदल जाती है। जब तक कि नुकसान स्पष्ट रूप से स्वीकार्य न हो और कोई अन्य स्रोत विश्वसनीय न हो, हटाने से पहले पुनः प्रयासों के साथ प्रोसेस करें।
फॉलो-अप 3: आउटबॉक्स क्या हल करता है?
यह व्यावसायिक स्थिति और एक लंबित इवेंट को एक डेटाबेस लेनदेन में कमिट करता है ताकि प्रकाशन को सुरक्षित रूप से पुनः प्रयास किया जा सके; डाउनस्ट्रीम उपभोक्ताओं को अभी भी इवेंट-आईडी आइडम्पोटेंसी की आवश्यकता होती है।
फॉलो-अप 4: आप यह कैसे साबित करेंगे कि कोई डुप्लिकेट शुल्क नहीं लगा है?
लिखने के बाद, विलोपन टाइमआउट के दौरान, और आउट-ऑफ-विंडो रीप्ले के बाद विफलताओं को इंजेक्ट करें। केवल कतार मेट्रिक्स के बजाय डेटाबेस विशिष्टता बाधा (uniqueness constraint), भुगतान प्रदाता की आइडम्पोटेंसी कुंजी और ऑडिट लॉग को सत्यापित करें।