प्रॉम्प्ट और दायरा
एक B2B एनालिटिक्स प्लेटफ़ॉर्म को रिपोर्ट-एक्सपोर्ट API की आवश्यकता है। एक एक्सपोर्ट में 5 मिनट से लेकर 3 घंटे तक का समय लगता है और यह 20 GiB जितनी बड़ी फ़ाइल उत्पन्न कर सकता है। सेवा को प्रत्येक दिन लगभग 09:00 बजे 10,000 सबमिशन प्राप्त हो सकते हैं। कॉल करने वालों में ब्राउज़र और अन्य कंपनियों द्वारा संचालित सेवाएं शामिल हैं। API गेटवे 30 सेकंड के बाद सिंक्रोनस अनुरोध को बंद कर देता है, इसलिए कॉल करने वाले प्रतिक्रिया न मिलने पर पुनः प्रयास कर सकते हैं।
उपयोगकर्ताओं को यह देखना चाहिए कि कार्य कतारबद्ध (queued) है, चल रहा है (running), सफल हुआ है (successful), या विफल रहा है (failed)। उन्हें संभव होने पर रद्दीकरण का अनुरोध करने और सफल परिणाम डाउनलोड करने की भी आवश्यकता होती है। अवधि, फ़ाइल आकार, पीक लोड, और टाइमआउट इंटरव्यू-केस के अनुमान हैं, न कि उद्योग सीमाएं। कतार विभाजन (Queue partitioning) इस प्रश्न के मुख्य केंद्र से बाहर है। मुख्य कार्य एक एसिंक्रोनस HTTP अनुबंध (contract) को परिभाषित करना है जो पुनः प्रयासों, प्रोसेस क्रैश और स्टेट रेस (state races) के बावजूद समझने योग्य बना रहे।
RFC 9110 कहता है कि 202 Accepted का अर्थ है कि अनुरोध को प्रोसेसिंग के लिए स्वीकार कर लिया गया है लेकिन प्रोसेसिंग अधूरी है और हो सकता है कि कभी न हो। प्रतिक्रिया में वर्तमान स्थिति का वर्णन होना चाहिए और स्टेटस मॉनिटर का संदर्भ दिया जाना चाहिए। एक वर्तमान सीनियर REST API इंटरव्यू गाइड भी उम्मीदवारों से लंबे समय तक चलने वाले ऑपरेशन्स को डिज़ाइन करने के लिए कहती है, जिसमें स्थिति, विफलता, रद्दीकरण, और आइडेम्पोटेंसी शामिल हैं। यह प्रश्न बैकएंड इंजीनियरों, API प्लेटफ़ॉर्म इंजीनियरों और सीनियर फ़ुल-स्टैक इंजीनियरों के लिए उपयुक्त है जो सेवा अनुबंध डिज़ाइन करते हैं, इसलिए इसकी मुख्य श्रेणी backend है।
इंटरव्यूअर क्या मूल्यांकन करता है
पहला, क्या उम्मीदवार 202 की सीमा को समझता है? इसका मतलब यह नहीं है कि "बैकग्राउंड जॉब सफल होगा," और अधूरा काम कोई अंतिम 200 OK परिणाम नहीं है। एक मजबूत उत्तर तुरंत पहचाने जाने योग्य अमान्य अनुरोधों को सिंक्रोनस रूप से अस्वीकार करता है, फिर ड्युरेबल स्वीकृति के बाद एक स्थिर ऑपरेशन रिसोर्स लौटाता है और बाद की स्थिति के रूप में निष्पादन परिणाम प्रदर्शित करता है।
दूसरा, क्या उम्मीदवार लंबे समय तक चलने वाले काम को केवल कतार संदेश ID लौटाने के बजाय एक रिसोर्स के रूप में मॉडल कर सकता है? एक ऑपरेशन को टेनेंट स्वामी, अनुरोध फ़िंगरप्रिंट, स्थिति, प्रगति, परिणाम या त्रुटि, संस्करण, निर्माण समय और समाप्ति की आवश्यकता होती है। इसकी स्टेट मशीन को अनुमत ट्रांज़िशन, टर्मिनल स्थितियों और रद्दीकरण रेस को परिभाषित करना चाहिए।
तीसरा, क्या कोई ऐसा अंतर है जिसमें सर्वर ने 202 लौटा दिया है लेकिन कार्य कभी कतारबद्ध नहीं हुआ? ऑपरेशन रिकॉर्ड और कार्य-से-प्रकाशित (work-to-publish) को एक ही ट्रांज़ैक्शन में सहेजा जाना चाहिए, फिर एक आउटबॉक्स प्रकाशक इसे कतारबद्ध कर सकता है। उपभोक्ताओं और निष्पादन चरणों को अभी भी आइडेम्पोटेंसी की आवश्यकता है क्योंकि एट-लीस्ट-वन्स डिलीवरी, वर्कर क्रैश, और लीज टेकओवर काम की डुप्लिकेट बना सकते हैं।
चौथा, क्या क्लाइंट अनुबंध वास्तविक ट्रैफ़िक का सामना कर सकता है? Location क्लाइंट को बताता है कि स्थिति का निरीक्षण कहाँ करना है। Retry-After, बैकऑफ़, जिटर और सशर्त अनुरोध पोलिंग को नियंत्रित करते हैं। हस्ताक्षरित वेबहुक सर्वर-टू-सर्वर कॉल करने वालों को सूचित कर सकते हैं, और SSE एक ब्राउज़र को अपडेट कर सकता है, लेकिन दोनों में से कोई भी रिकवरी के लिए एक पूछताछ योग्य (queryable) ऑपरेशन रिसोर्स की जगह नहीं लेता है।
अंत में, इंटरव्यूअर को एक सुरक्षा और सत्यापन की कहानी सुननी चाहिए। एक अनअंदाज़नीय ID ऑब्जेक्ट-स्तरीय प्राधिकरण (authorization) नहीं है, और एक परिणाम URL को टेनेंट सीमाओं को बायपास नहीं करना चाहिए। एक मजबूत उत्तर खोई हुई स्वीकृति प्रतिक्रियाओं, डुप्लिकेट सबमिशन, प्रकाशन विफलता, वर्कर क्रैश, रद्दीकरण-समापन रेस, पोलिंग बर्स्ट, और समाप्ति सफ़ाई का परीक्षण करता है।
पहले स्पष्ट करने योग्य प्रश्न
- सिंक्रोनस रूप से क्या मान्य किया जाना चाहिए? पहचान, टेनेंट अनुमति, अनुरोध आकार, इनपुट का अस्तित्व, और स्पष्ट कोटा उल्लंघनों की जांच स्वीकृति से पहले की जानी चाहिए। यदि डेटा पूर्णता केवल कई घंटों के स्कैन के बाद ही पता चल सकती है, तो वह एक एसिंक्रोनस निष्पादन विफलता है, स्वीकृति पर किया गया वादा नहीं।
- क्या डुप्लिकेट अनुरोध का अर्थ पुनः प्रयास है या दूसरा स्वतंत्र ऑपरेशन? जब कॉल करने वाले
Idempotency-Keyप्रदान करते हैं, तो वही टेनेंट, एंडपॉइंट, कुंजी और अनुरोध फ़िंगरप्रिंट को एक ही ऑपरेशन को फिर से चलाना चाहिए। एक कॉलर जिसे जानबूझकर दो समान निर्यातों की आवश्यकता है, उसे दो कुंजियों का उपयोग करना चाहिए। - क्या प्रगति मापने योग्य है? यदि विभाजनों की कुल संख्या ज्ञात है, तो पूर्ण और कुल इकाइयों की रिपोर्ट करें। यदि यह अनुमान लगाने योग्य नहीं है, तो 99% तक जाने वाले प्रतिशत का आविष्कार करने के बजाय चरण और अंतिम हार्टबीट की रिपोर्ट करें।
- परिणाम किस प्रकार का रिसोर्स है? एक छोटा परिणाम ऑपरेशन प्रतिक्रिया में एम्बेड किया जा सकता है। एक बड़ी फ़ाइल एक अलग संरक्षित रिसोर्स होनी चाहिए। यह केस अल्पकालिक डाउनलोड क्रेडेंशियल और ऑपरेशन मेटाडेटा, परिणाम ऑब्जेक्ट और डाउनलोड क्रेडेंशियल के लिए अलग-अलग प्रतिधारण अवधियों का उपयोग करता है।
- रद्दीकरण क्या वादा करता है? क्या यह केवल भविष्य के काम को रोकता है, या इसे पहले से प्रतिबद्ध साइड इफेक्ट्स को पूर्ववत करना चाहिए? यदि चरण अपरिवर्तनीय हैं, तो अनुबंध को सर्वोत्तम-प्रयास रद्दीकरण, मुआवज़ा (compensation), आंशिक आउटपुट, और संभावित अंतिम स्थितियों को परिभाषित करना चाहिए।
- कॉल करने वाले कौन से अधिसूचना चैनल प्राप्त कर सकते हैं? ब्राउज़र आमतौर पर कॉलबैक एंडपॉइंट्स होस्ट नहीं कर सकते हैं, इसलिए पोलिंग या SSE उपयुक्त हैं। सर्वर-टू-सर्वर कॉल करने वाले वेबहुक का उपयोग कर सकते हैं। नेटवर्क की बाधाएं और विलंबता लक्ष्य अधिसूचना चैनल को बदलते हैं, लेकिन ऑपरेशन रिसोर्स सत्य का स्रोत बना रहता है।
- क्या समानांतर ऑपरेशन्स टकरा सकते हैं? क्या एक रिपोर्ट कॉन्फ़िगरेशन को समवर्ती रूप से निर्यात किया जा सकता है? जब निष्पादन के दौरान उस कॉन्फ़िगरेशन को अपडेट या हटाया जाता है तो क्या होता है? उत्तर यह निर्धारित करता है कि क्या क्रमबद्ध करना है, इनपुट का स्नैपशॉट लेना है, संघर्षों को अस्वीकार करना है, या पुराने संस्करण को समाप्त होने देना है।
- स्थिति को कितने समय तक बनाए रखा जाता है? यह केस टर्मिनल ऑपरेशन्स को 7 दिनों के लिए, परिणाम ऑब्जेक्ट्स को 24 घंटों के लिए, और प्रत्येक डाउनलोड क्रेडेंशियल को 15 मिनट के लिए बनाए रखता है। ये उत्पाद-अनुबंध विकल्प हैं जिन्हें ऑडिट आवश्यकताओं, लागत और परिणामों को पुनर्जीवित करने की क्षमता के साथ बदलना चाहिए।
30-सेकंड उत्तर रूपरेखा
"मैं निष्पादन को HTTP अनुरोध से अलग करूँगा, लेकिन मैं केवल एक जॉब ID नहीं लौटाऊँगा। सबमिशन एंडपॉइंट ऑथराइजेशन और तुरंत पहचाने जाने योग्य त्रुटियों को मान्य करता है, फिर एक ट्रांज़ैक्शन में एक ऑपरेशन और एक आउटबॉक्स रिकॉर्ड लिखता है। एक बार कमिट हो जाने के बाद, यह 202, Location, और एक सुझाई गई पोलिंग अंतराल लौटाता है। एक अधिकृत ऑपरेशन रिसोर्स स्थिर स्थिति, वास्तविक प्रगति, संरचित त्रुटियों और परिणाम लिंक को प्रदर्शित करता है। वही आइडेम्पोटेंसी कुंजी और अनुरोध उसी ऑपरेशन को फिर से चलाते हैं। वर्कर ऑपरेशन ID द्वारा आइडेम्पोटेंट रूप से प्रोसेस करते हैं, जबकि संस्करण स्थितियां स्टेट ट्रांज़िशन की रक्षा करती हैं। पोलिंग Retry-After, बैकऑफ़, और जिटर का उपयोग करती है; सर्वर कॉल करने वाले हस्ताक्षरित वेबहुक जोड़ सकते हैं; रद्दीकरण cancel_requested में प्रवेश करता है और पूर्णता के साथ अपनी रेस को हल करता है। फिर मैं खोई हुई प्रतिक्रियाओं, डुप्लिकेट संदेशों, वर्कर क्रैश, रद्दीकरण रेस, और समाप्ति को इंजेक्ट करूँगा ताकि यह साबित हो सके कि कोई घोस्ट जॉब्स, डुप्लिकेट दृश्य परिणाम, या अनधिकृत डाउनलोड नहीं हैं।"
स्टेप-बाय-स्टेप डीप डाइव
पहला, दो रिसोर्स परिभाषित करें। एक निर्यात अनुरोध उस परिणाम को व्यक्त करता है जिसे उपयोगकर्ता बनाना चाहता है, जबकि एक ऑपरेशन रिसोर्स इस निष्पादन के जीवनचक्र का प्रतिनिधित्व करता है। सबमिशन POST /v1/report-exports हो सकता है, और स्थिति GET /v1/report-operations/{operation_id} हो सकती है। स्वीकृति प्रतिक्रिया हो सकती है:
HTTP/1.1 202 Accepted
Location: /v1/report-operations/op_7f3a
Retry-After: 5
Content-Type: application/json
{
"id": "op_7f3a",
"status": "queued",
"statusUrl": "/v1/report-operations/op_7f3a",
"cancelUrl": "/v1/report-operations/op_7f3a"
}202 केवल यह वादा करता है कि प्रोसेसिंग स्वीकार कर ली गई थी। एक विकृत (malformed) अनुरोध, अनधिकृत कॉलर, या गैर-मौजूद इनपुट को उपयुक्त 4xx के साथ अस्वीकार करें और कोई ऑपरेशन न बनाएं। एक व्यावसायिक विफलता जिसके लिए महंगी गणना की आवश्यकता होती है, उसे ऑपरेशन रिसोर्स में बनाए रखें। Location और Retry-After इस API के क्लाइंट अनुबंध का हिस्सा हैं; RFC 9110 के लिए प्रत्येक 202 प्रतिक्रिया को दोनों हेडर का उपयोग करने की आवश्यकता नहीं है।
दूसरा, ऑपरेशन रिकॉर्ड और स्टेट मशीन को परिभाषित करें। एक न्यूनतम रिकॉर्ड में id, tenant_id, idempotency_key, request_fingerprint, status, प्रगति, एक परिणाम संदर्भ, एक संरचित त्रुटि, version, निर्माण और अद्यतन टाइमस्टैम्प, और expires_at शामिल हैं। एक अनुशंसित ट्रांज़िशन सेट है:
queued -> running -> succeeded
-> failed
queued -> cancel_requested -> canceled
running -> cancel_requested -> canceled | succeeded | failedरद्दीकरण और पूर्णता में रेस हो सकती है, इसलिए cancel_requested टर्मिनल नहीं है। एक वर्कर version और एक अनुमत पूर्व स्थिति पर सशर्त अद्यतन के साथ एक परिणाम कमिट करता है; केवल एक ही ट्रांज़िशन जीतता है। यदि कोई साइड इफेक्ट पहले से ही अपरिवर्तनीय है, तो रद्दीकरण अंततः succeeded या failed बन सकता है। केवल बटन लेबल से मेल खाने के लिए canceled न बनाएं। एक स्थिति प्रतिनिधित्व इस तरह दिख सकता है:
{
"id": "op_7f3a",
"status": "running",
"progress": {
"completedUnits": 37,
"totalUnits": 100
},
"result": null,
"error": null,
"lastUpdatedAt": "2026-07-18T23:18:11Z",
"expiresAt": "2026-07-25T23:08:11Z"
}इस प्रगति को केवल तभी लौटाएं जब कार्य इकाइयों में एक वास्तविक भाजक (denominator) हो। एक विफल निष्पादन अभी भी 200 लौटा सकता है जब ऑपरेशन स्वयं सफलतापूर्वक पढ़ा जाता है, जिसमें विफलता को टर्मिनल स्थिति और एक संरचित error द्वारा दर्शाया जाता है: स्थिति पढ़ना सफल रहा जबकि प्रतिनिधित्व निष्पादन विफल रहा। एक टीम जो इसके बजाय स्थिति एंडपॉइंट से 4xx में निष्पादन विफलता को मैप करती है, उसे दोनों अर्थों को मिलाने के बजाय प्रत्येक SDK में लगातार उस परंपरा का उपयोग करना चाहिए।
तीसरा, स्वीकृति, पुनः प्रयास, और निष्पादन को सही बनाएं। (tenant_id, route, idempotency_key) पर एक अद्वितीय बाधा (unique constraint) लगाएं और विहित अनुरोध (canonical request) का एक फ़िंगरप्रिंट संग्रहीत करें। वही कुंजी और फ़िंगरप्रिंट मौजूदा ऑपरेशन और वर्तमान स्थिति लौटाते हैं। एक अलग फ़िंगरप्रिंट वाली वही कुंजी एक स्पष्ट संघर्ष लौटाती है, जो किसी अन्य रिपोर्ट के लिए आकस्मिक कुंजी पुनर्चक्रण को रोकती है। आइडेम्पोटेंसी रिकॉर्ड को कम से कम तब तक बनाए रखें जब तक कि क्लाइंट वैध रूप से पुनः प्रयास कर सकें और इसे ऑपरेशन प्रतिधारण के साथ समन्वित कर सकें।
ऑपरेशन और आउटबॉक्स इवेंट को एक डेटाबेस ट्रांज़ैक्शन में डालें, फिर 202 लौटाएं। एक अलग प्रकाशक आउटबॉक्स इवेंट को कतार में भेजता है और इसे एक से अधिक बार भेज सकता है। उपभोक्ता ऑपरेशन ID द्वारा डिडुप्लिकेट करते हैं। प्रत्येक निष्पादन चरण को आइडेम्पोटेंट लिखने या एक फ़ेंसिंग टोकन की भी आवश्यकता होती है ताकि बाहरी लेखन के बाद वर्कर क्रैश, जिसके बाद टेकओवर होता है, दो दृश्य परिणाम उत्पन्न न करे। API उत्तर को स्वीकृति-से-कतार सीमा को साबित करने की आवश्यकता है; इसे एक पूर्ण शेड्यूलर डिज़ाइन को पुन: प्रस्तुत करने की आवश्यकता नहीं है।
चौथा, स्थिति और अधिसूचना ट्रैफ़िक को नियंत्रित करें। प्रारंभिक और बाद की स्थिति प्रतिक्रियाएं एक उचित Retry-After प्रदान करती हैं। क्लाइंट कैप और जिटर के साथ घातीय बैकऑफ़ का उपयोग करते हैं, जबकि सर्वर अपरिवर्तित बॉडी को फिर से भेजने से बचने के लिए ETag और सशर्त अनुरोधों का समर्थन करता है। यदि स्थिति पढ़ना कोटे से अधिक हो जाता है, तो 10,000 कॉल करने वालों को हर सेकंड पोल करने की अनुमति देने के बजाय दर-सीमा (rate-limit) जानकारी लौटाएं।
एक ब्राउज़र जिसे कम-विलंबता प्रगति की आवश्यकता होती है, वह SSE की सदस्यता ले सकता है और डिस्कनेक्ट होने के बाद भी ऑपरेशन ID द्वारा क्वेरी कर सकता है। एक सर्वर कॉलर एक हस्ताक्षरित वेबहुक पंजीकृत कर सकता है; प्रेषक पुनः प्रयास करता है, और प्राप्तकर्ता डिडुप्लिकेट करता है। दोनों पुश चैनल खो सकते हैं, विलंबित हो सकते हैं, या डुप्लिकेट हो सकते हैं, इसलिए ऑपरेशन रिसोर्स रिकवरी और समाधान के लिए सत्य का स्रोत बना रहता है। सफलता पर, ऑपरेशन बॉडी परिणाम से लिंक कर सकती है। यदि API इसके बजाय एक अलग परिणाम रिसोर्स पर रीडायरेक्ट करता है, तो 303 सिमेंटिक्स का दस्तावेजीकरण करें और सत्यापित करें कि SDKs परिणाम स्थान पर मूल POST को फिर से न चलाएं।
पांचवां, ऑथराइजेशन, रद्दीकरण, और प्रतिधारण को संभालें। प्रत्येक स्थिति पढ़ना, रद्दीकरण, और परिणाम पुनर्प्राप्ति tenant_id, कॉलर पहचान, और ऑपरेशन अनुमति पर ऑब्जेक्ट-स्तरीय ऑथराइजेशन करती है। यादृच्छिक ID गणना (enumeration) को कठिन बनाते हैं लेकिन वे ऑथराइजेशन नहीं हैं। डाउनलोड सेवा परिणाम के स्वामित्व को फिर से सत्यापित करती है, फिर इस मामले के लिए चुने गए 15-मिनट के क्रेडेंशियल जारी करती है। ऑपरेशन प्रतिक्रिया कभी भी लंबे समय तक चलने वाले सार्वजनिक URL को संग्रहीत नहीं करती है।
DELETE /v1/report-operations/{id} एक रद्दीकरण अनुरोध व्यक्त कर सकता है। यदि रद्दीकरण संभव है, तो यह दिखाने के लिए कि इसे स्वीकार कर लिया गया था, वर्तमान cancel_requested प्रतिनिधित्व लौटाएं। यदि यह असंभव है या ऑपरेशन पहले से ही टर्मिनल है, तो एक स्थिर प्रतिक्रिया लौटाएं जिसे पुनः प्रयास करना सुरक्षित हो। वर्कर स्टेज सीमाओं पर रद्दीकरण मार्कर का निरीक्षण करते हैं, भविष्य के चरणों को छोड़ते हैं, और अस्थायी वस्तुओं को हटाते हैं। पहले से प्रतिबद्ध बाहरी प्रभाव पूर्वनिर्धारित मुआवज़ा नियम का पालन करते हैं। 7 दिनों के बाद एक टर्मिनल ऑपरेशन को हटा दें। एक ज्ञात समाप्त ID प्रकटीकरण नीति के अनुसार 410 Gone लौटा सकती है, जबकि एक अज्ञात या अनधिकृत ID 404 लौटा सकती है।
छठा, केवल हैप्पी पाथ के बजाय विफलताओं का सत्यापन करें। कम से कम इन मामलों को कवर करें: सर्वर कमिट करता है लेकिन 202 प्रतिक्रिया खो देता है, और पुनः प्रयास केवल उसी ऑपरेशन को पुनर्प्राप्त कर सकता है; आउटबॉक्स प्रकाशक भेजने से पहले या बाद में क्रैश हो जाता है, और कार्य अंततः एक दृश्य परिणाम के साथ मौजूद होता है; परिणाम लिखने के बाद एक वर्कर अपनी पावती खो देता है, और उसका उत्तराधिकारी टर्मिनल स्थिति को अधिलेखित (overwrite) नहीं कर सकता है; रद्दीकरण और पूर्णता एक साथ आते हैं, और केवल एक कानूनी टर्मिनल स्थिति प्रकट होती है; अपरिवर्तित स्थिति पोलिंग बैकऑफ़ और सशर्त अनुरोधों का पालन करती है; क्रॉस-टेनेंट स्थिति, रद्दीकरण, और डाउनलोड सभी विफल होते हैं; मेटाडेटा, परिणाम, और आइडेम्पोटेंसी कुंजियाँ अनुबंध के अनुसार समाप्त होती हैं।
पुन: प्रयोज्य निर्णय नियम है: 202 कनेक्शन प्रतीक्षा को हल करता है, ऑपरेशन रिसोर्स अवलोकनीयता (observability) को हल करता है, और परमाणु स्वीकृति प्लस एक आइडेम्पोटेंट स्टेट मशीन शुद्धता को हल करती है।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं पहले स्वीकृति की सफलता को निष्पादन की सफलता से अलग करूँगा। ऑपरेशन में 3 घंटे लग सकते हैं और यह 30 सेकंड तक चलने वाले गेटवे कनेक्शन पर कब्जा नहीं कर सकता। POST /v1/report-exports इसलिए पहचान, टेनेंट अनुमति, अनुरोध आकार, इनपुट अस्तित्व, और स्पष्ट कोटा उल्लंघनों की जांच करता है। फिर यह एक ट्रांज़ैक्शन में ऑपरेशन और आउटबॉक्स रिकॉर्ड बनाता है और कमिट के बाद ही 202 लौटाता है। प्रतिक्रिया में ऑपरेशन रिसोर्स के लिए Location और पहले स्टेटस रीड के लिए Retry-After शामिल है। 202 यह वादा नहीं करता है कि रिपोर्ट सफल होगी।
ऑपरेशन टेनेंट स्वामित्व, आइडेम्पोटेंसी कुंजी, अनुरोध फ़िंगरप्रिंट, स्थिति, सत्यापन योग्य प्रगति, परिणाम या त्रुटि, संस्करण, और समाप्ति को संग्रहीत करता है। स्थिति queued से running और फिर succeeded या failed में बदलती है। रद्दीकरण पहले cancel_requested में प्रवेश करता है क्योंकि वर्कर उसी समय परिणाम कमिट कर रहा हो सकता है। एक ही टेनेंट और एंडपॉइंट के तहत, वही आइडेम्पोटेंसी कुंजी और अनुरोध एक ऑपरेशन लौटाते हैं; एक अलग अनुरोध के साथ वही कुंजी एक संघर्ष है। इसलिए क्लाइंट द्वारा पुनः प्रयास करने पर खोई हुई 202 प्रतिक्रिया दूसरी रिपोर्ट नहीं बना सकती है।
मैं एट-लीस्ट-वन्स कतार डिलीवरी मानकर चलता हूँ। आउटबॉक्स दो बार प्रकाशित हो सकता है, उपभोक्ता ऑपरेशन ID पर डिडुप्लिकेट करते हैं, और प्रत्येक चरण में बाहरी लेखन आइडेम्पोटेंट या fenced होते हैं। स्थिति अपडेट में संस्करण स्थितियां शामिल होती हैं ताकि लीज पर लिए जाने के बाद एक पुराना वर्कर परिणाम को अधिलेखित न कर सके। स्वीकृति से पहले विफलता तुरंत 4xx लौटाती है। निष्पादन के दौरान विफलता को टर्मिनल स्थिति और संरचित त्रुटि के रूप में संग्रहीत किया जाता है, जिससे क्लाइंट नेटवर्क विफलता, स्थिति-पढ़ने की विफलता, और रिपोर्ट-निष्पादन विफलता में अंतर कर सकते हैं।
क्लाइंट घातीय बैकऑफ़ और जिटर के साथ Retry-After के अनुसार पोल करते हैं, और स्थिति एंडपॉइंट ETag का समर्थन करता है। एक ब्राउज़र लाइव प्रगति के लिए SSE का उपयोग कर सकता है और एक भागीदार सेवा हस्ताक्षरित वेबहुक का उपयोग कर सकती है, लेकिन दोनों डिस्कनेक्ट या डुप्लिकेट अधिसूचना के बाद ऑपरेशन रिसोर्स के माध्यम से पुनर्प्राप्त होते हैं। परिणाम फ़ाइल का कभी भी सार्वजनिक URL नहीं होता है। डाउनलोड एंडपॉइंट फिर से अधिकृत करता है और 15-मिनट का क्रेडेंशियल जारी करता है। इस मामले में, टर्मिनल ऑपरेशन्स 7 दिनों तक और फ़ाइलें 24 घंटों तक जीवित रहती हैं, और वे समाप्ति नियम सार्वजनिक अनुबंध हैं।
अंत में, मैं कमिट के बाद खोई हुई प्रतिक्रिया, बार-बार आउटबॉक्स डिलीवरी, परिणाम लिखने के बाद वर्कर क्रैश, रद्दीकरण-पूर्णता रेस, एक साथ पोलिंग करने वाले 10,000 कॉलर्स, और क्रॉस-टेनेंट एक्सेस का परीक्षण करूँगा। पास होने का मतलब बैकग्राउंड में एक बार पूरा होने से कहीं अधिक है: इन विफलताओं से घोस्ट जॉब्स, डुप्लिकेट दृश्य परिणाम, अवैध ट्रांज़िशन, या अनधिकृत डाउनलोड नहीं बनने चाहिए।"
सामान्य गलतियाँ
- 202 लौटाने के बाद इन-मेमोरी थ्रेड शुरू करना → एक प्रक्रिया पुनः आरंभ होने पर ऐसा काम छूट जाता है जो कभी नहीं मिल सकता, और स्वीकृति लॉन्च के साथ परमाणु नहीं होती है → स्वीकृति स्वीकार करने से पहले ऑपरेशन और आउटबॉक्स को बनाए रखें।
- 202 को अंतिम सफलता मानना → HTTP स्पष्ट रूप से प्रोसेसिंग को कभी न होने देने या विफल होने की अनुमति देता है → बाद के अनुबंध में अंतिम परिणाम, त्रुटियां और एक स्थिति मॉनिटर प्रदर्शित करें।
- केवल एक कतार संदेश ID लौटाना → इसमें टेनेंट स्वामित्व, स्थिर स्थिति, त्रुटियां, परिणाम, और प्रतिधारण का अभाव होता है → एक अलग अधिकृत ऑपरेशन रिसोर्स बनाएं।
- हमेशा के लिए प्रति सेकंड एक बार पोलिंग करना → एक सबमिशन पीक एक निरंतर रीड पीक बन जाता है → Retry-After प्रदान करें और बैकऑफ़, जिटर, ETag, और कोटा का उपयोग करें।
- एक यादृच्छिक ऑपरेशन ID को प्राधिकरण के रूप में उपयोग करना → एक लीक हुआ लॉग, ब्राउज़र इतिहास प्रविष्टि, या आंतरिक लिंक अभी भी क्रॉस-टेनेंट एक्सेस प्रदान करता है → प्रत्येक स्थिति पढ़ने, रद्दीकरण, और परिणाम पुनर्प्राप्ति को अधिकृत करें।
- आइडेम्पोटेंसी कुंजी को केवल एक छोटे Redis लॉक में रखना → लॉक समाप्ति, क्रैश, और परिणाम पुनः चलाना अभी भी डुप्लिकेट ऑपरेशन्स बना सकते हैं → एक ड्युरेबल विशिष्टता बाधा, अनुरोध फ़िंगरप्रिंट, और पुन: प्रयोज्य प्रतिक्रिया का उपयोग करें।
- उपयोगकर्ता द्वारा क्लिक करते ही रद्द के रूप में चिह्नित करना → हो सकता है कि वर्कर ने पहले ही एक अपरिवर्तनीय प्रभाव कमिट कर दिया हो → पहले cancel_requested में प्रवेश करें और सशर्त ट्रांज़िशन प्लस मुआवज़े को कानूनी टर्मिनल स्थिति निर्धारित करने दें।
- हमेशा प्रतिशत का आविष्कार करना → अप्रत्याशित चरण 99% पर रुक जाते हैं और कॉल करने वालों को गुमराह करते हैं → मापने योग्य होने पर पूर्ण इकाइयों की रिपोर्ट करें, अन्यथा चरण और अद्यतन समय की रिपोर्ट करें।
- वेबहुक सफल होने के बाद ऑपरेशन को हटाना → अधिसूचना खो सकती है, डुप्लिकेट हो सकती है, या अस्थायी रूप से टूटे हुए रिसीवर द्वारा स्वीकार की जा सकती है → ऑपरेशन को समयबद्ध पुनर्प्राप्ति स्रोत के रूप में बनाए रखें।
फॉलो-अप प्रश्न
फॉलो-अप 1: डेटाबेस ट्रांज़ैक्शन कमिट हो गया, लेकिन 202 प्रतिक्रिया खो गई। जब क्लाइंट फिर से सबमिट करता है तो क्या होता है?
क्लाइंट मूल Idempotency-Key का पुन: उपयोग करता है। सर्वर टेनेंट, एंडपॉइंट, और कुंजी द्वारा ऑपरेशन का पता लगाता है, पुष्टि करता है कि अनुरोध फ़िंगरप्रिंट मेल खाता है, और किसी अन्य ऑपरेशन या आउटबॉक्स रिकॉर्ड को डाले बिना वर्तमान प्रतिनिधित्व और Location को फिर से चलाता है। यदि कुंजी मेल खाती है लेकिन अनुरोध भिन्न होता है, तो एक संघर्ष लौटाएं और एक नई कुंजी की आवश्यकता रखें। परीक्षण को यह साबित करना होगा कि एक ऑपरेशन पंक्ति और एक दृश्य परिणाम है, भले ही कतार वितरण डुप्लिकेट हो।
फॉलो-अप 2: ऑपरेशन 90% पूरा हो गया है। रद्दीकरण और परिणाम कमिट एक साथ आते हैं। कौन सी स्थिति जीतती है?
अग्रिम में कानूनी ट्रांज़िशन को परिभाषित करें और एक विजेता का चयन करने के लिए संस्करण-सशर्त अद्यतन का उपयोग करें। यदि परिणाम ट्रांज़ैक्शन पहले running से succeeded कमिट करता है, तो बाद का रद्दीकरण टर्मिनल succeeded स्थिति को पढ़ता है और लौटाता है। यदि रद्दीकरण पहले cancel_requested तक पहुंचता है, तो वर्कर जांचता है कि कमिट करने से पहले पूर्णता की अनुमति अभी भी है या नहीं। एक अपरिवर्तनीय चरण कानूनी रूप से cancel_requested को succeeded या failed में समाप्त कर सकता है; अनुबंध पूर्ण रोलबैक का वादा नहीं कर सकता है।
फॉलो-अप 3: प्रगति का अनुमान लगाने योग्य नहीं है, लेकिन उत्पाद प्रतिशत पर जोर देता है। आप क्या लौटाते हैं?
बताएं कि एक मनगढ़ंत प्रतिशत गलत उम्मीद पैदा करता है। पूर्ण किए गए चरणों, वर्तमान चरण, अंतिम हार्टबीट, और ऐतिहासिक रनों से प्राप्त एक गैर-बाध्यकारी सीमा दिखाएं। completedUnits / totalUnits केवल तभी लौटाएं जब कुल कार्यभार स्थिर हो। यदि व्यक्तिगत चरण मापने योग्य हैं, तो विभिन्न लागतों वाले चरणों का औसत निकालने के बजाय प्रत्येक चरण के भीतर प्रगति दिखाएं।
फॉलो-अप 4: एक पार्टनर पोल करने से मना करता है। क्या API को केवल वेबहुक प्रदर्शित करना चाहिए?
एक वेबहुक सामान्य-पथ विलंबता और रीड्स को कम कर सकता है, लेकिन यह एकमात्र रिकवरी तंत्र नहीं हो सकता है। कॉलबैक DNS, प्रमाणपत्र, फ़ायरवॉल, हस्ताक्षर-कुंजी रोटेशन, डुप्लिकेट, और ऑर्डरिंग विफलताओं का सामना करते हैं। वेबहुक डिलीवरी पर हस्ताक्षर करें और पुनः प्रयास करें, ऑपरेशन ID और संस्करण शामिल करें, और रिसीवर डिडुप्लिकेशन की आवश्यकता रखें। पार्टनर छूटी हुई घटना के बाद ऑपरेशन रिसोर्स के माध्यम से सामंजस्य (reconcile) स्थापित कर सकता है। बिना स्थिर कॉलबैक एंडपॉइंट वाले ब्राउज़र पोलिंग या SSE का उपयोग करना जारी रखते हैं।
फॉलो-अप 5: एक रिपोर्ट 20 GiB की फ़ाइल उत्पन्न करती है। क्या ऑपरेशन API को सीधे डाउनलोड URL लौटाना चाहिए?
ऑपरेशन को एक परिणाम-रिसोर्स संदर्भ लौटाना चाहिए। मामले के 15-मिनट के डाउनलोड क्रेडेंशियल जारी करने से पहले टेनेंट और कॉलर को फिर से अधिकृत करें। ऑपरेशन में लंबे समय तक चलने वाले ऑब्जेक्ट-स्टोर URL को बनाए न रखें। फ़ाइल 24 घंटों तक जीवित रहती है जबकि ऑपरेशन मेटाडेटा 7 दिनों तक रहता है, इसलिए फ़ाइल समाप्त होने के बाद भी ऑपरेशन यह कह सकता है कि निष्पादन सफल रहा, आर्टिफ़ैक्ट समाप्त हो गया, और पुनर्जनन उपलब्ध है।
फॉलो-अप 6: स्थिति-क्वेरी ट्रैफ़िक निष्पादन ट्रैफ़िक से बड़ा हो जाता है। आप पहले क्या बदलते हैं?
पहले पुष्टि करें कि क्लाइंट Retry-After, घातीय बैकऑफ़, एक कैप, और जिटर का पालन करते हैं। फिर ETag-आधारित सशर्त अनुरोध, टेनेंट कोटा, और दर सीमित करने (rate limiting) को सक्षम करें। जिन ब्राउज़रों को कम विलंबता की आवश्यकता होती है वे SSE के माध्यम से अपडेट समेकित कर सकते हैं, और सर्वर कॉल करने वाले वेबहुक का उपयोग कर सकते हैं, जबकि कम-आवृत्ति स्थिति रीड उपलब्ध रहती है। सुझाई गई अंतराल में भी जिटर जोड़ें ताकि 09:00 सबमिशन पीक स्थिति एंडपॉइंट पर सिंक्रनाइज़ आवधिक पीक न बने।