प्रश्न और यह कब लागू होता है
एक ऐसा एसिंक्रोनस मैसेज फ़्लो डिज़ाइन करें जिसमें मैसेजेस सीमित रिट्राइज़ (bounded retries) के बाद डेड-लेटर क्यू (DLQ) में चले जाते हैं और ऑपरेटर्स कारण को ठीक करने के बाद चुने हुए मैसेजेस को रिप्ले कर सकते हैं। आइसोलेशन, इन्वेस्टिगेशन, बैच सिलेक्शन, डुप्लिकेट साइड इफ़ेक्ट्स और सामान्य ट्रैफ़िक के लिए सुरक्षा को स्पष्ट करें।
Amazon के सॉफ़्टवेयर-डेवलपमेंट इंटरव्यू के विषय समस्याओं को हल करने के लिए ज्ञान को लागू करने पर ज़ोर देते हैं। AWS, DLQs को रिट्री लिमिट्स और अलार्म्स के साथ अनकंज्यूम्ड मैसेजेस के आइसोलेशन के रूप में प्रलेखित करता है; Google Pub/Sub डेड-लेटर टॉपिक्स और रिप्ले या seek सिमेंटिक्स को प्रलेखित करता है। मुख्य बात एक ऑपरेशनल रिकवरी लूप है, न कि केवल एक क्यू डायग्राम।
इंटरव्यूअर्स क्या आंकते हैं
- ट्रांसिएंट एरर्स, पॉइज़न मैसेजेस, बिज़नेस रिजेक्शन और एक्सपायरी का वर्गीकरण।
- वर्ज़न, टेनेंट, पार्टीशन, ट्रेस, प्रयासों (attempts), और विफलता के कारण के लिए मेटाडेटा।
- रिप्ले नियंत्रण: इडेम्पोटेंसी, स्कोप, रेट, अप्रूवल और स्टॉप कंडीशन्स।
- ऑर्डरिंग, रिटेंशन, डुप्लिकेट डिलीवरी और at-least-once सिमेंटिक्स।
- ऐसे मेट्रिक्स जो केवल मैसेजेस को वापस ले जाने के बजाय वास्तविक रिकवरी को साबित करते हैं।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- क्या डिलीवरी at-least-once, at-most-once, या बिज़नेस-लेवल exactly-once है?
- कौन सी विफलताएं रिट्राइएबल (retryable) हैं?
- मैसेजेस को कब तक रिटेन किया जाता है और वे कब अपनी वैल्यू खो देते हैं?
- क्या एग्रीगेट की (aggregate key) के लिए ऑर्डर आवश्यक है?
- क्या कंज्यूमर्स इडेम्पोटेंट साइड इफ़ेक्ट्स बना सकते हैं?
- मैसेजेस का निरीक्षण, रिप्ले या डिलीट कौन कर सकता है?
- सामान्य SLOs, क्यू क्षमता और रिप्ले क्षमता क्या हैं?
- क्या विफल रिप्ले उसी DLQ में जाता है या replay-DLQ में?
30-सेकंड का उत्तर फ़्रेमवर्क
"मैं पहले डिलीवरी सिमेंटिक्स, रिटेंशन और ऑर्डरिंग कीज़ को परिभाषित करता हूँ। रिट्राइएबल एरर्स सीमित बैकऑफ़ का उपयोग करते हैं; पॉइज़न और बिज़नेस-रिजेक्शन मैसेजेस कारण, प्रयास, वर्ज़न और ट्रेस ID के साथ DLQ में जाते हैं। सुधार के बाद, एक ऑपरेटर एक स्कोप्ड रिप्ले बैच बनाता है, आइसोलेशन में एक सैंपल को मान्य करता है, और एक सीमित दर पर रिप्ले करता है। कंज्यूमर्स इडेम्पोटेंसी कीज़ के साथ साइड इफ़ेक्ट्स की रक्षा करते हैं। मैं DLQ आयु, रिप्ले विफलताओं, डुप्लिकेट्स और डाउनस्ट्रीम लेटेंसी की निगरानी करता हूँ, और थ्रेशोल्ड पार होने पर रोक देता हूँ।"
विस्तृत उत्तर, चरण-दर-चरण
चरण 1: विफलता स्टेट मशीन को परिभाषित करें
सामान्य, रिट्राई, DLQ, मैनुअल-फ़िक्स, और replay-DLQ स्टेट्स को अलग करें। स्थायी बिज़नेस विफलताओं को हमेशा के लिए रिट्राई नहीं किया जाना चाहिए।
चरण 2: मैसेज मेटाडेटा को परिभाषित करें
इवेंट ID, बिज़नेस इडेम्पोटेंसी की, क्रिएशन टाइम, टेनेंट या पार्टीशन, स्कीमा वर्ज़न, प्रयास, ओरिजिनल ट्रेस ID और एरर क्लास को बनाए रखें। ओरिजिनल पेलोड को अपरिवर्तनीय (immutably) रूप से सुरक्षित रखें।
चरण 3: रिट्राई और DLQ नियम सेट करें
अधिकतम रिसीव, बैकऑफ़ और रिटेंशन चुनें। AWS SQS सोर्स-क्यू और Region बाधाओं को प्रलेखित करता है और DLQ अलार्म्स की सिफारिश करता है। एक्सपायर्ड या रिवोक किए गए मैसेजेस के लिए ऑडिटेड डिस्पोज़िशन की आवश्यकता होती है।
चरण 4: रिप्ले को सुरक्षित बनाएं
एक रिप्ले अनुरोध में फ़िल्टर, टारगेट कंज्यूमर वर्ज़न, रेट लिमिट, बैच साइज़, अप्रूवर और एक्सपायरी शामिल होती है। पहले एक सैंपल को मान्य करें, फिर बैचों में रिप्ले करें। रिप्ले क्षमता को सामान्य ट्रैफ़िक से अलग रखें।
| नियंत्रण | उद्देश्य | विफलता पर कार्रवाई |
|---|---|---|
| इडेम्पोटेंसी की | डुप्लिकेट साइड इफ़ेक्ट्स को रोकना | अस्वीकार करें या पिछला परिणाम लौटाएं |
| रेट लिमिट | कंज्यूमर्स और डिपेंडेंसीज़ की सुरक्षा करना | रिप्ले को रोकें |
| बैच स्कोप | ब्लास्ट रेडियस को सीमित करना | फ़िल्टर को संकीर्ण करें |
| अप्रूवल और ऑडिट | जवाबदेही स्थापित करना | अनधिकृत कार्रवाई को ब्लॉक करें |
| Replay-DLQ | बार-बार होने वाली विफलताओं को अलग करना | एक नया डायग्नोसिस बैच बनाएं |
चरण 5: ऑर्डरिंग और कॉनकरेंसी को संभालें
जब ऑर्डर मायने रखता है, तो एग्रीगेट की द्वारा पार्टीशन करें और सामान्य और रिप्ले कंज्यूमर्स को एक ही की को एक साथ प्रोसेस करने से रोकें। केवल क्यू के आधार पर एंड-टू-एंड exactly-once डिलीवरी का दावा न करें।
चरण 6: साइड इफ़ेक्ट्स को सुरक्षित करें
कंडीशनल राइट्स के लिए इवेंट IDs या बिज़नेस इडेम्पोटेंसी कीज़ का उपयोग करें। पेमेंट्स और ईमेल के लिए इडेम्पोटेंट रिक्वेस्ट कीज़ और रिज़ल्ट लुकअप की आवश्यकता होती है; मैसेज को डिलीट करना रोलबैक नहीं है।
चरण 7: ऑब्ज़र्वेबिलिटी के साथ संचालन करें
DLQ डेप्थ, सबसे पुरानी आयु, एरर क्लासेस, रिप्ले थ्रूपुट, रिप्ले विफलताएं, डुप्लिकेट इफ़ेक्ट्स और डाउनस्ट्रीम लेटेंसी की निगरानी करें। प्रत्येक बैच के लिए ऑपरेटर, कारण, स्कोप, समय, परिणाम और स्टॉप इवेंट्स रिकॉर्ड करें।
चरण 8: क्षमता का बजट बनाएं और सुरक्षित रूप से रोकें
रिप्ले क्षमता का अनुमान लगाएं और नए कंज्यूमर्स को पुराने स्कीमा के साथ कम्पैटिबल रखें। जब कारण ठीक न हुआ हो, डिपेंडेंसीज़ ओवरलोड हो जाएं, या डुप्लिकेट रेट बढ़ जाए, तो रोकें; साक्ष्य को सुरक्षित रखें।
उच्च-गुणवत्ता वाला नमूना उत्तर
"यह एक at-least-once ऑर्डर-इवेंट फ़्लो है। नेटवर्क टाइमआउट्स बैकऑफ़ के साथ पाँच बार तक रिट्राई होते हैं; स्कीमा एरर्स, ऑथराइज़ेशन विफलताएं और एक्सपायर्ड इवेंट्स DLQ में प्रवेश करते हैं। प्रत्येक मैसेज में इवेंट ID, ऑर्डर ID, टेनेंट, स्कीमा वर्ज़न, फ़र्स्ट-एनक्यू टाइम, प्रयास, एरर क्लास और ट्रेस ID रखी जाती है।
सुधार के बाद, एक ऑपरेटर टेनेंट और टाइम विंडो, टारगेट वर्ज़न, रेट लिमिट, अप्रूवर और एक्सपायरी चुनता है। पचास मैसेजेस को एक अलग कंज्यूमर में मान्य किया जाता है, फिर रिप्ले सामान्य ट्रैफ़िक के दस प्रतिशत पर चलता है। ऑर्डर स्टेट इवेंट ID द्वारा कीड कंडीशनल राइट का उपयोग करती है, और पेमेंट अनुरोध बिज़नेस इडेम्पोटेंसी की का पुन: उपयोग करते हैं। एक ऑर्डर के लिए सामान्य और रिप्ले प्रोसेसिंग एक साथ नहीं चल सकती।
अलर्ट्स सबसे पुरानी आयु, रिप्ले विफलताओं, डुप्लिकेट राइट्स और डिपेंडेंसी लेटेंसी को कवर करते हैं। कोई भी थ्रेशोल्ड बैच को रोक देता है और बार-बार होने वाली विफलताओं को एक replay-DLQ में रूट करता है। बैच रिकॉर्ड में फ़िल्टर, वर्ज़न, ऑपरेटर, परिणाम और रुकने का कारण शामिल होता है।"
सामान्य गलतियाँ
- बिना किसी साक्ष्य के DLQ को कचरा पात्र (trash can) समझना।
- पॉइज़न मैसेजेस को हमेशा के लिए रिट्राई करते रहना।
- बिना स्कोप, अप्रूवल या रेट कंट्रोल के फिर से कतारबद्ध (requeue) करना।
- यह मान लेना कि क्यू एंड-टू-एंड exactly-once प्रदान करती है।
- इडेम्पोटेंसी को छोड़ देना और डुप्लिकेट शुल्क या ईमेल उत्पन्न करना।
- ऑर्डरिंग कीज़ को नज़रअंदाज़ करना।
- केवल क्यू की लंबाई की निगरानी करना।
- बिना सुरक्षा के रिप्ले और सामान्य ट्रैफ़िक के बीच क्षमता साझा करना।
फ़ॉलो-अप प्रश्न और उनके उत्तर कैसे दें
फ़ॉलो-अप 1: रिट्राई के प्रयासों को क्यों न बढ़ाएं?
रिट्राई ट्रांसिएंट फ़ॉल्ट्स के लिए उपयुक्त हैं; पॉइज़न और स्थायी बिज़नेस विफलताएं क्षमता की खपत करती हैं। फ़ॉल्ट के प्रकार, रिटेंशन और बिज़नेस वेटिंग कॉस्ट के आधार पर सीमाएं निर्धारित करें।
फ़ॉलो-अप 2: आप एक ऑर्डर के लिए ऑर्डर कैसे सुरक्षित रखते हैं?
ऑर्डर की द्वारा पार्टीशन करें, एक साथ सामान्य और रिप्ले प्रोसेसिंग को ब्लॉक करें, और बताएं कि स्टेट ट्रांज़िशन्स पुराने इवेंट्स को कैसे अस्वीकार करते हैं।
फ़ॉलो-अप 3: क्या होगा यदि डिपेंडेंसी इडेम्पोटेंट नहीं है?
लोकल डिडुप्लिकेशन और रिज़ल्ट लुकअप का उपयोग करें; अन्यथा मैनुअल रीकॉन्सिलेशन, कॉम्पेन्सेशन, या प्रोवाइडर इडेम्पोटेंसी मैकेनिज़्म की आवश्यकता होती है।
फ़ॉलो-अप 4: क्या होगा यदि रिप्ले फिर से विफल हो जाता है?
इसे एक अलग replay-DLQ पर भेजें, मूल बैच और नए एरर को बनाए रखें, प्रभावित फ़िल्टर को रोकें, और ओनर को सूचित करें।
फ़ॉलो-अप 5: आप रिप्ले रेट कैसे चुनते हैं?
कंज्यूमर क्षमता, डिपेंडेंसी कोटा, सामान्य हेडरूम और रिकवरी समय का उपयोग करें। दर बढ़ाने से पहले एक छोटे बैच का लोड-टेस्ट करें।
फ़ॉलो-अप 6: आप किसी मैसेज को कब डिस्कार्ड कर सकते हैं?
केवल एक स्पष्ट बिज़नेस निर्णय के बाद कि यह एक्सपायर्ड, रिवोक या महत्वहीन है, ऑडिट साक्ष्य और एक सुरक्षित कारण के साथ।"