प्रांप्ट और पृष्ठभूमि
एक इवेंट प्रोड्यूसर बाहरी HTTP एंडपॉइंट्स पर व्यावसायिक इवेंट्स उत्सर्जित करता है। प्लेटफ़ॉर्म को इवेंट्स को स्थायी रूप से सुरक्षित रखना चाहिए, कम से कम एक बार (at least once) डिलीवर करना चाहिए, डुप्लिकेट्स को सुरक्षित बनाना चाहिए, और प्रत्येक टेनेंट को स्पष्ट पुनः प्रयास (retry) और रीप्ले नियंत्रण प्रदान करना चाहिए।
साक्षात्कारकर्ता क्या जांचता है
- HTTP पर ठीक एक बार (exactly once) का वादा करने के बजाय एक स्पष्ट डिलीवरी गारंटी चुनना।
- इनजेशन, शेड्यूलिंग, डिलीवरी प्रयासों और सब्सक्राइबर-साइड प्रभावों (side effects) को अलग करना।
- इवेंट IDs, सिग्नेचर टाइमस्टैम्प, रीट्राई पॉलिसी, डेड-लेटर हैंडलिंग और निष्पक्षता (fairness) का संयोजन करना।
उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
- इवेंट की मात्रा, पेलोड आकार, एंडपॉइंट संख्या और अधिकतम डिलीवरी विलंब क्या है?
- क्या प्रति टेनेंट, प्रति एंडपॉइंट, या बिल्कुल भी क्रमबद्धता (ordering) की आवश्यकता है?
- क्या उपभोक्ता किसी इवेंट को आइडम्पोटेंटली (idempotently) प्रोसेस कर सकते हैं, और डिडुप्लिकेशन स्थिति कितने समय तक रहनी चाहिए?
- पेलोड पर कौन से रीप्ले, विलोपन, गोपनीयता और ऑडिट आवश्यकताएं लागू होती हैं?
30-सेकंड का उत्तर ढांचा
मैं एक स्थिर ID के साथ एक अपरिवर्तनीय (immutable) इवेंट को सुरक्षित रखूंगा, डिलीवरी प्रयासों को कतारबद्ध (enqueue) करूंगा, और रिसीवर पथ से त्वरित रूप से वापस आऊंगा। वर्कर्स टाइमस्टैम्प के साथ रॉ पेलोड पर हस्ताक्षर करते हैं, जिटर (jitter) के साथ घातीय बैकऑफ़ (exponential backoff) लागू करते हैं, और प्रतिक्रियाओं को पुनः प्रयास योग्य और अंतिम विफलताओं में वर्गीकृत करते हैं। उपभोक्ता साइड इफेक्ट्स से पहले इवेंट ID द्वारा डिडुप्लिकेट करते हैं। प्रति-टेनेंट शेड्यूलर, सर्किट ब्रेकर और डेड-लेटर कतार किसी एक ऑफ़लाइन एंडपॉइंट को दूसरों के संसाधनों को समाप्त करने से रोकते हैं; रीप्ले मूल इवेंट पहचान को बदले बिना एक नया प्रयास बनाता है।
चरण-दर-चरण गहन विश्लेषण
1. पहले इवेंट को टिकाऊ (durable) बनाएं
व्यावसायिक इवेंट और उसके डिलीवरी रिकॉर्ड को ट्रांजैक्शनल रूप से या एक विश्वसनीय आउटबॉक्स के माध्यम से लिखें। डिलीवरी रिकॉर्ड टेनेंट, एंडपॉइंट, इवेंट ID, प्रयास संख्या, अगले प्रयास का समय और स्थिति संग्रहीत करता है। भेजने के बाद लेकिन सफलता रिकॉर्ड करने से पहले क्रैश होना अपेक्षित है; यह एक और प्रयास उत्पन्न करता है, इसलिए उपभोक्ताओं को डुप्लिकेट्स सहन करने में सक्षम होना चाहिए।
2. सुरक्षित रूप से सत्यापित करें और हस्ताक्षर करें
सटीक रॉ बाइट्स और टाइमस्टैम्प पर हस्ताक्षर करें, और हस्ताक्षरित संदेश में इवेंट ID शामिल करें। रीप्ले हमलों को सीमित करने के लिए Stripe टाइमस्टैम्प वाले हस्ताक्षरों का दस्तावेजीकरण करता है। उपभोक्ता पार्स करने से पहले सिग्नेचर को सत्यापित करते हैं, कॉन्फ़िगर की गई सहनशीलता से बाहर के टाइमस्टैम्प को अस्वीकार करते हैं, और पहले से कतारबद्ध इवेंट को अप्रत्याशित रूप से अमान्य किए बिना सीक्रेट्स को रोटेट करते हैं।
3. प्रतिक्रियाओं को वर्गीकृत करें और पुनः प्रयास करें
नेटवर्क टाइमआउट, कनेक्शन विफलताओं और चयनित 5xx प्रतिक्रियाओं को पुनः प्रयास योग्य मानें। विकृत प्रमाणीकरण, असमर्थित इवेंट संस्करणों और अधिकांश 4xx प्रतिक्रियाओं को अंतिम या ऑपरेटर-समीक्षित मानें। जिटर के साथ एक्सपोनेंशियल बैकऑफ़, एक अधिकतम प्रयास विंडो और एक डेड-लेटर स्थिति का उपयोग करें। स्थायी रूप से विफल हो रहे एंडपॉइंट पर अनिश्चित काल तक पुनः प्रयास न करें।
4. डुप्लिकेट्स और रीप्ले को स्पष्ट बनाएं
उपभोक्ता संसाधित इवेंट IDs को एक टिकाऊ विशिष्टता बाधा (uniqueness constraint) के साथ संग्रहीत करता है और जब संभव हो तो व्यावसायिक साइड इफेक्ट के साथ उस रिकॉर्ड को कमिट करता है। एक मैनुअल रीप्ले अपरिवर्तनीय इवेंट पेलोड का पुन: उपयोग करता है और एक नए डिलीवरी प्रयास को रिकॉर्ड करता है, जबकि डैशबोर्ड मूल डिलीवरी, स्वचालित पुनः प्रयास और ऑपरेटर रीप्ले के बीच अंतर करते हैं। एक्ज़ैक्टली-वन्स साइड इफेक्ट्स के लिए उपभोक्ता ट्रांजैक्शन की आवश्यकता होती है; नेटवर्क स्वयं केवल ऐट-लीस्ट-वन्स डिलीवरी प्रदान करता है।
5. क्रॉस-टेनेंट भुखमरी (starvation) के बिना स्केल करें
कतारों को टेनेंट या एंडपॉइंट द्वारा विभाजित (partition) करें, प्रति-टेनेंट समवर्ती (concurrency) और दर सीमाएं लागू करें, और स्वस्थ टेनेंट्स के लिए क्षमता आरक्षित करें। सर्किट ब्रेकर बार-बार विफल होने के बाद एंडपॉइंट को रोक देता है। मेट्रिक्स में सबसे पुराने लंबित इवेंट की आयु, सफलता विलंबता, प्रयास वितरण, डुप्लिकेट दर, सिग्नेचर विफलताएं और डेड-लेटर मात्रा शामिल होनी चाहिए।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं डिलीवरी शेड्यूल करने से पहले प्रत्येक इवेंट को एक स्थिर ID के साथ बनाए रखूंगा और ऐट-लीस्ट-वन्स सिमेंटिक्स का वादा करूंगा। प्रत्येक प्रयास रॉ पेलोड पर एक इवेंट ID और टाइमस्टैम्प के साथ हस्ताक्षर करता है। वर्कर्स जिटर वाले पुनः प्रयास के लिए टाइमआउट और 5xx प्रतिक्रियाओं को वर्गीकृत करते हैं, जबकि टर्मिनल 4xx प्रतिक्रियाएं डेड लेटर में चली जाती हैं। उपभोक्ता अपने साइड-इफ़ेक्ट ट्रांजैक्शन के अंदर इवेंट IDs को डिडुप्लिकेट करते हैं। प्रति-टेनेंट कतारें, सर्किट ब्रेकर, आयु-आधारित अलर्ट और एक रीप्ले वर्कफ़्लो एक ऑफ़लाइन सब्सक्राइबर को दूसरों के संसाधन छीनने से रोकते हैं और रिकवरी को ऑडिट योग्य बनाते हैं।”
सामान्य गलतियाँ
- HTTP पर exactly-once का वादा करना → क्रैश अस्पष्ट परिणाम उत्पन्न करते हैं → at-least-once बताएं और आइडम्पोटेंट उपभोक्ताओं की आवश्यकता रखें।
- रॉ बाइट्स के बजाय पार्स किए गए JSON पर हस्ताक्षर करना → समान स्वरूपण भी सत्यापन में विफल हो सकता है → सटीक पेलोड बाइट्स पर हस्ताक्षर करें और सत्यापित करें।
- हर 4xx को हमेशा के लिए पुनः प्रयास करना → स्थायी विफलताएं क्षमता का उपभोग करती हैं → त्रुटियों को वर्गीकृत करें और टर्मिनल मामलों को डेड-लेटर करें।
- एक वैश्विक कतार का उपयोग करना → एक टेनेंट सभी को भूखा रख सकता है → विभाजित करें, दर-सीमा लागू करें, और प्रति-टेनेंट क्षमता आरक्षित करें।
अनुवर्ती प्रश्न और उत्तर
डिडुप्लिकेशन स्थिति कितने समय तक रहनी चाहिए?
कम से कम तब तक जब तक स्वचालित पुनः प्रयास और समर्थित रीप्ले विंडो चलती है, साथ ही एक सुरक्षा मार्जिन। यदि रीप्ले महीनों बाद हो सकता है, तो एक संक्षिप्त इवेंट लेज़र बनाए रखें या उपभोक्ताओं को स्पष्ट रूप से रीप्ले पहचान और प्रतिधारण नीति चुनने की आवश्यकता दें।
क्या रीप्ले को एक नया इवेंट ID मिलना चाहिए?
आमतौर पर नहीं: व्यावसायिक इवेंट पहचान स्थिर रहती है, जबकि डिलीवरी प्रयास को अपना ID और ऑडिट रिकॉर्ड मिलता है। यह उपभोक्ताओं को रीप्ले को उसी इवेंट के रूप में पहचानने देता है और डुप्लिकेट व्यावसायिक प्रभावों को रोकता है।
क्या होगा यदि कोई उपभोक्ता अपने साइड इफेक्ट के कमिट होने से पहले 200 लौटाता है?
उपभोक्ता अनुबंध टूट जाता है; प्लेटफ़ॉर्म प्रतिक्रिया से सफलता का अनुमान नहीं लगा सकता है। उपभोक्ताओं को टिकाऊ स्वीकृति के बाद पावती (acknowledge) देनी चाहिए, इनबॉक्स या ट्रांजैक्शनल डिडुप्लिकेशन रिकॉर्ड का उपयोग करना चाहिए, और अस्पष्ट परिणामों के लिए समाधान (reconciliation) प्रस्तुत करना चाहिए।