प्रॉम्प्ट और संदर्भ
भुगतान, टिकट और संसाधन-निर्माण API किसी अनुरोध को निष्पादित कर सकते हैं जबकि उसका रिस्पॉन्स खो सकता है। सुरक्षित पुनर्प्रयासों के लिए ग्राहक Idempotency-Key चाहते हैं। यह तय करें कि इसे लॉन्च किया जाए या नहीं और इसके वादे, लक्षित ग्राहकों, मेट्रिक्स, लागत और रोलबैक को परिभाषित करें।
साक्षात्कारकर्ता क्या जांचता है
क्या आप एक प्रोटोकॉल क्षमता को एक सत्यापन योग्य प्रोडक्ट अनुबंध में बदल सकते हैं: समर्थित ऑपरेशन, की (key) का जीवनकाल, पैरामीटर मिसमैच, डुप्लिकेट रिस्पॉन्स, और विश्वसनीयता, स्टोरेज लागत व डेवलपर अनुभव के बीच संतुलन (trade-off)?
स्पष्ट करने योग्य प्रश्न
स्पष्ट करें कि दर्दनाक दुष्प्रभाव (side effect) डुप्लिकेट शुल्क है, डुप्लिकेट संसाधन है, या डुप्लिकेट सूचना; फिर अनुरोध की मात्रा, पुनर्प्रयास विंडो, मल्टी-रीजन आवश्यकताओं और अवधारण (retention) नियमों के बारे में पूछें। सर्वर डिडुप्लीकेशन को व्यावसायिक पूर्णता से अलग रखें ताकि वादा एक असमर्थित exactly-once दावा न बन जाए।
30-सेकंड का उत्तर
"मैं उच्च-जोखिम वाले राइट्स (writes) के लिए सीमित इडेम्पोटेंसी लॉन्च करूँगा, न कि हर एंडपॉइंट के लिए exactly-once का वादा करूँगा। अनुबंध में की (key) प्रारूप, टेनेंट स्कोप, अवधारण विंडो, पैरामीटर फ़िंगरप्रिंट और डुप्लिकेट रिस्पॉन्स को परिभाषित किया जाना चाहिए; अलग-अलग पैरामीटर वाली समान की में विरोध (conflict) होना चाहिए। मैं भुगतान और संसाधन निर्माण में पायलट करूँगा, डुप्लिकेट दुष्प्रभावों, सुरक्षित-पुनर्प्रयास सफलता, स्टोरेज लागत और सपोर्ट मामलों को मापूँगा, फिर स्पष्ट 409/422 सिमेंटिक्स के साथ ऑप्ट-इन कैनरी के माध्यम से इसका विस्तार करूँगा।"
चरण-दर-चरण गहन विश्लेषण
उपयोगकर्ता मूल्य को परिभाषित करें
"टाइमआउट के बाद पुनः प्रयास करना सुरक्षित है" को परिणाम बनाएं और वित्तीय या संसाधन दुष्प्रभावों वाले POST ऑपरेशनों को प्राथमिकता दें। केवल-पढ़ने योग्य (read-only) कॉल्स और स्वाभाविक रूप से इडेम्पोटेंट PUTs को मार्केटिंग कारणों से इस जटिलता की आवश्यकता नहीं है।
अनुबंध सीमा लिखें
टेनेंट-स्कोप वाली विशिष्टता, लंबाई सीमाएं, अवधारण और पुनः प्रयास करने योग्य स्थितियों को परिभाषित करें। पहली स्थिति और बॉडी को स्टोर करें; गलत परिणाम का चुपचाप पुन: उपयोग करने के बजाय अलग-अलग मापदंडों वाली समान की में विरोध होना चाहिए।
व्यावसायिक लेन-देन से कनेक्ट करें
डिडुप्लीकेशन रिकॉर्ड को दुष्प्रभाव के साथ एक विश्वसनीय लेनदेन साझा करना चाहिए या एक पुनर्प्राप्ति योग्य आउटबॉक्स का उपयोग करना चाहिए। कैश हिट डाउनस्ट्रीम सेटलमेंट को साबित नहीं करता है; एसिंक्रोनस कार्य को एक क्वेरी योग्य ऑपरेशन आईडी वापस करनी चाहिए।
त्रुटियों और अनुकूलता को डिज़ाइन करें
प्रगति पर (in-progress), सफल (succeeded), विफल (failed) और समाप्त (expired) के बीच अंतर करें। SDK, दस्तावेज़ और गेटवे को की (key) को लगातार आगे अग्रेषित करना चाहिए। पुराने क्लाइंट काम करना जारी रख सकते हैं, लेकिन उन्हें अंतर्निहित पुनर्प्रयास गारंटी नहीं मिलनी चाहिए।
मेट्रिक्स और लागत चुनें
प्राथमिक मेट्रिक्स के रूप में डुप्लिकेट दुष्प्रभाव दर और सुरक्षित-पुनर्प्रयास सफलता को ट्रैक करें; सुरक्षा उपायों (guardrails) में की-स्टोर क्षमता, P95 लेटेंसी, विरोध दर और सपोर्ट वॉल्यूम शामिल हैं। हमेशा के लिए रिस्पॉन्स बनाए रखने के बजाय टेनेंट जोखिम द्वारा TTL और स्टोरेज सेट करें।
चरणों में रोल आउट करें
एक क्षेत्र, भुगतान सैंडबॉक्स और आंतरिक SDK से शुरुआत करें। शैडो डिडुप लॉग के साथ हिट दर को मान्य करें, फिर एक छोटे टेनेंट कोहोर्ट को ऑप्ट-इन करने दें। यदि रिस्पॉन्स अलग होते हैं, स्टोरेज नियंत्रण से बाहर हो जाता है, या डाउनस्ट्रीम में लेनदेन समर्थन का अभाव होता है, तो पुराने पथ को संरक्षित करते हुए नए प्रवेश बिंदु को अक्षम करें।
मॉडल उत्तर
मैं इडेम्पोटेंसी कीज़ को उच्च-जोखिम वाले राइट्स के लिए पुनर्प्रयास-सुरक्षा अनुबंध के रूप में स्थापित करूँगा। भुगतान और संसाधन निर्माण से शुरुआत करें; टेनेंट स्कोप, की प्रारूप, अवधारण, पैरामीटर फ़िंगरप्रिंट और डुप्लिकेट रिस्पॉन्स को परिभाषित करें। परस्पर विरोधी पैरामीटर विफल होने चाहिए, और एसिंक्रोनस दुष्प्रभावों के लिए एक क्वेरी योग्य ऑपरेशन आईडी की आवश्यकता होती है। डुप्लिकेट दुष्प्रभावों, सुरक्षित-पुनर्प्रयास सफलता, P95 लेटेंसी, विरोध दर और स्टोरेज लागत को मापें। सैंडबॉक्स और ऑप्ट-इन कैनरी में पायलट करें, और जब लेनदेन या डाउनस्ट्रीम समर्थन गायब हो तो वादे का विस्तार न करें।
सामान्य गलतियाँ
exactly-once का वादा करना
एक इडेम्पोटेंसी की मुख्य रूप से डुप्लिकेट क्लाइंट सबमिशन को हटाती है; यह एक अप्राप्य डाउनस्ट्रीम दुष्प्रभाव को कवर नहीं कर सकती है। at-most-once हैंडलिंग और अंतिम-स्थिति लुकअप को स्पष्ट रूप से बताएं।
हमेशा के लिए कीज़ को बनाए रखना
स्थायी अवधारण लागत, गोपनीयता और सफाई की समस्याएं पैदा करता है। जोखिम के आधार पर TTL को परिभाषित करें और समाप्ति के बाद के व्यवहार का दस्तावेजीकरण करें।
पैरामीटर परिवर्तनों की अनदेखी करना
किसी भिन्न अनुरोध के लिए पहला परिणाम वापस करना क्लाइंट बग को छुपाता है। एक पैरामीटर फ़िंगरप्रिंट स्टोर करें और एक विरोध (conflict) लौटाएं।
केवल गेटवे कैश लागू करना
गेटवे कैशिंग को व्यावसायिक लेनदेन से अलग किया जा सकता है। डिडुप रिकॉर्ड को विश्वसनीय निरंतरता या पुनर्प्राप्ति योग्य क्षतिपूर्ति की आवश्यकता होती है।
अनुवर्ती प्रश्न
हर POST का समर्थन क्यों नहीं करते?
दुष्प्रभाव और लागत भिन्न होते हैं। कम-मूल्य वाले एंडपॉइंट पर एक जटिल अनुबंध लगाने के बजाय पहले उच्च-जोखिम वाले परिदृश्यों को कवर करें।
क्या होगा यदि पहला अनुरोध अभी भी चल रहा है?
मतदान (polling) या सदस्यता के लिए एक स्पष्ट प्रगति-पर स्थिति और ऑपरेशन आईडी लौटाएं; समवर्ती रूप से दूसरा दुष्प्रभाव निष्पादित न करें।
आप विभिन्न क्षेत्रों में कीज़ को सुसंगत कैसे रखते हैं?
एक प्राथमिक क्षेत्र या टेनेंट शार्पिंग से शुरुआत करें। मल्टी-रीजन समर्थन के लिए केवल कैश प्रतिकृति ही नहीं, बल्कि सुसंगत डिडुप स्टोरेज और विफलता अभ्यास (failure drills) की आवश्यकता होती है।
क्या विफल रिस्पॉन्स का पुन: उपयोग किया जा सकता है?
अनुबंध को पुनः प्रयास करने योग्य क्षणिक विफलताओं को अंतिम विफलताओं से अलग करना चाहिए और यह दस्तावेजित करना चाहिए कि स्थिति और बॉडी कैश्ड हैं या नहीं। Stripe पहला परिणाम संग्रहीत करता है, इसलिए ग्राहकों को TTL और त्रुटि सिमेंटिक्स को समझना चाहिए।