प्रॉम्प्ट और संदर्भ
उत्पादक (producers) रिट्राइज़, संस्करणित पेलोड और असमान ट्रैफ़िक के साथ CloudEvents भेजते हैं। गेटवे को एनवेलप्स को मान्य (validate) करना चाहिए, टेनेंट्स को अलग (isolate) रखना चाहिए, डिलीवरी के प्रमाण को सुरक्षित रखना चाहिए, और उपभोक्ताओं के लिए कम से कम एक बार (at-least-once) वाले व्यवहार को स्पष्ट बनाना चाहिए।
इंटरव्यूअर क्या जांचता है
- एक प्रोटोकॉल एनवेलप को स्पष्ट इंजेक्शन और डिलीवरी अनुबंधों में बदलना।
- आइडमपोटेंसी का दायरा, रिट्री स्थिति और टिकाऊ हैंडऑफ़ सीमाओं का चयन करना।
- टेनेंट आइसोलेशन, स्कीमा इवोल्यूशन और परिचालन प्रमाण डिज़ाइन करना।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- प्रत्येक टेनेंट को प्रति सेकंड कितने पीक इवेंट्स और किस पेलोड आकार का समर्थन करना चाहिए?
- क्या उत्पादकों को अनिश्चित काल तक रिट्री करने की अनुमति है, और क्या प्रति स्रोत (source) या विषय (subject) के आधार पर क्रमबद्धता (ordering) आवश्यक है?
- किन उपभोक्ताओं को कम से कम एक बार डिलीवरी की आवश्यकता है, और क्या वे स्रोत और ID द्वारा डुप्लीकेट हटा सकते हैं?
- क्या स्कीमा केंद्रीय रूप से पंजीकृत हैं, और रीप्ले के लिए कच्चे इवेंट्स को कब तक बनाए रखा जाना चाहिए?
30-सेकंड उत्तर फ्रेमवर्क
मैं एक प्रमाणित एज पर TLS समाप्त करूँगा, CloudEvents एनवेलप और टेनेंट कोटा को मान्य करूँगा, फिर पावती (acknowledgement) देने से पहले कच्चे इवेंट को स्थायी रूप से जोड़ूँगा। एक विभाजित कतार (partitioned queue) कम से कम एक बार डिलीवरी का उपयोग करके उपभोक्ताओं को फैन-आउट करती है; (tenant, source, id) डुप्लीकेशन हटाने की कुंजी है जब निर्माता इसकी स्थिरता की गारंटी देता है। उपभोक्ता पावती, पुनः प्रयास शेड्यूल, डेड लेटर्स, स्कीमा संस्करण और प्रति-टेनेंट सीमाएं हानि और दोहराव को अंतर्निहित के बजाय दृश्यमान बनाती हैं।
चरण-दर-चरण गहन विश्लेषण
1. इनजेस्ट और मान्य करें
संरचित या बाइनरी HTTP बाइंडिंग स्वीकार करें, आकार और कंटेंट-टाइप सीमाएं लागू करें, और specversion, type, source, और id जैसे आवश्यक विशेषताओं को मान्य करें। टेनेंट को प्रमाणित करें और टिकाऊ काम से पहले एक अमान्य एनवेलप को अस्वीकार करें। ऑडिट और रीप्ले के लिए प्राप्त सटीक बाइट्स और हेडर को सुरक्षित रखें।
2. टिकाऊ सीमा चुनें
सफलता वापस करने से पहले एक टिकाऊ ऑपरेशन में एक अपरिवर्तनीय इवेंट रिकॉर्ड और एक आउटबॉक्स या लॉग ऑफ़सेट लिखें। केवल-कतार पावती में इवेंट खोने का जोखिम होता है यदि कतार प्रकाशन कमिट नहीं किया गया है; केवल-डेटाबेस डिज़ाइन उच्च-मात्रा वाले फ़ैन-आउट को बाधित कर सकता है। लेटेंसी और टिकाऊपन के ट्रेड-ऑफ़ को स्पष्ट रूप से बताएं।
3. रिट्राइज़ को छिपाए बिना डुप्लीकेट हटाएं
निर्माता के पुनः प्रयासों को कवर करने वाली अवधारण (retention) अवधि के साथ एक टेनेंट-स्कोप्ड (source, id) कुंजी का उपयोग करें। पेलोड डाइजेस्ट और स्कीमा संस्करण संग्रहीत करें; अलग-अलग बाइट्स वाली समान कुंजी एक टकराव है जिसके लिए क्वारंटाइन की आवश्यकता होती है। डिलीवरी प्रयासों को तार्किक इवेंट से अलग रखें ताकि पुनः प्रयास अवलोकनीय बने रहें।
4. वितरित करें और पुनः प्रयास करें
उपभोक्ता विभाजनों से खींचते हैं (pull) या लीज के साथ पुश की गई डिलीवरी प्राप्त करते हैं। एक सफल पावती प्रयास को आगे बढ़ाती है; टाइमआउट और क्षणिक विफलताएं जिटर (jitter) के साथ एक्सपोनेंशियल बैकऑफ़ शेड्यूल करती हैं। स्थायी विफलताएं रीप्ले नियंत्रण और ऑडिट रिकॉर्ड के साथ टेनेंट-स्कोप्ड डेड-लेटर स्ट्रीम में चली जाती हैं।
5. विकसित और संचालित करें
इनग्रेस पर स्कीमा संस्करणों को मान्य करें, असंगत इवेंट्स को क्वारंटाइन में रूट करें, और उपभोक्ता क्षमता घोषणाओं का समर्थन करें। टेनेंट और स्रोत द्वारा स्वीकृत, अस्वीकृत, डुप्लिकेट, विलंबित, पुनः प्रयास किए गए, डेड-लेटर किए गए और रीप्ले किए गए इवेंट्स को मापें। रहस्यों या अप्रतिबंधित पेलोड को लॉग किए बिना कोटा, एन्क्रिप्शन, अवधारण और एक्सेस नियंत्रण लागू करें।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं एज पर प्रत्येक टेनेंट को प्रमाणित करूँगा, CloudEvents एनवेलप को मान्य करूँगा, आकार और कोटा सीमाएं लागू करूँगा, और पावती देने से पहले सटीक इवेंट और हेडर को स्थायी रूप से जोड़ूँगा। इसके बाद एक विभाजित लॉग कम से कम एक बार वितरित करता है। जब निर्माता ID स्थिरता की गारंटी देता है, तो डिडुप्लीकेशन कुंजी टेनेंट प्लस स्रोत प्लस ID होती है; समान कुंजी के लिए बदले हुए डाइजेस्ट को क्वारंटाइन किया जाता है। उपभोक्ता प्रयासों की पुष्टि करते हैं, क्षणिक विफलताएं जिटर के साथ बैकऑफ़ करती हैं, और स्थायी विफलताएं रीप्ले करने योग्य डेड-लेटर स्ट्रीम में जाती हैं। स्कीमा संस्करण, प्रति-टेनेंट मेट्रिक्स, अवधारण और ऑडिट लॉग डिलीवरी सिमेंटिक्स को स्पष्ट बनाते हैं।”
सामान्य गलतियां
- स्थायी रूप से जोड़ने से पहले स्वीकार करना → क्रैश होने पर इवेंट खो जाता है → चुनी गई टिकाऊ सीमा के बाद पावती (ack) दें।
- वैश्विक स्तर पर ID द्वारा डिडुप्लीकेट करना → टेनेंट या स्रोत टकरा सकते हैं → कुंजी का दायरा सीमित करें और डाइजेस्ट सत्यापित करें।
- सटीक रूप से एक बार (exactly-once) का वादा करना → पुनः प्रयास और उपभोक्ता प्रभाव अभी भी संभव हैं → कम से कम एक बार बताएं और आइडमपोटेंट उपभोक्ताओं की आवश्यकता रखें।
- असंगत स्कीमा को छोड़ देना → डिबगिंग और रीप्ले असंभव हो जाता है → संस्करणित साक्ष्य के साथ क्वारंटाइन करें।
फॉलो-अप प्रश्न और उत्तर
क्या गेटवे क्रमबद्धता की गारंटी दे सकता है?
केवल एक परिभाषित दायरे के भीतर, जैसे कि स्रोत और विषय विभाजन। अनुक्रम मेटाडेटा को सुरक्षित रखें, उसी कुंजी को एक विभाजन में रूट करें, और यह प्रलेखित करें कि पुनः प्रयास या समानांतर उपभोक्ता बाद के इवेंट्स में देरी कर सकते हैं।
क्या होगा यदि कोई उत्पादक विभिन्न पेलोड के लिए एक ही ID का पुन: उपयोग करता है?
संग्रहीत डाइजेस्ट की तुलना करें और टकराव को अस्वीकार या क्वारंटाइन करें। पहले इवेंट को कभी भी चुपचाप ओवरराइट न करें; उत्पादक को सचेत करें क्योंकि डिडुप्लीकेशन अनुबंध टूट गया है।
आप टेनेंट-विशिष्ट रीप्ले का समर्थन कैसे करते हैं?
प्राधिकरण-बद्ध रीप्ले टोकन, एक नया प्रयास ID, दर सीमाएं (rate limits) और एक ऑडिट ट्रेल के साथ अपरिवर्तनीय इवेंट रिकॉर्ड रखें। रीप्ले को स्कीमा और डिडुप्लीकेशन जांच पास करनी होगी और उपभोक्ता अलगाव को बायपास नहीं करना चाहिए।