बैकएंड इंटरव्यू: आंशिक विफलताओं (partial failures) वाले बैच API को आप कैसे डिज़ाइन करेंगे?

प्रांप्ट और कार्यक्षेत्र (Scope)

यह प्रश्न यह जांचता है कि क्या कोई बैकएंड इंजीनियर "बैच" को सटीक निष्पादन (execution) और परिणाम सिमेंटिक्स दे सकता है या नहीं। मान लें कि कोई ग्राहक ऑर्डर लेबल या यूजर सेटिंग्स को थोक (bulk) में अपडेट करना चाहता है; आइटम स्वतंत्र हो सकते हैं या कोटा, वर्जन अथवा डिपेंडेंसी साझा कर सकते हैं, और सर्वर द्वारा कुछ आइटम पूरे करने के बाद नेटवर्क टाइमआउट हो सकता है। आपको सिंक्रोनस और एसिंक्रोनस सीमाओं को परिभाषित करना होगा ताकि क्लाइंट सुरक्षित रूप से आगे बढ़ सके।

यह बैकएंड इंजीनियर्स, API डिज़ाइनर्स और प्लेटफ़ॉर्म इंजीनियर्स के लिए उपयुक्त है। किसी विशिष्ट REST, gRPC या कतार (queue) के विकल्प के बजाय एटॉमिसीटी (atomicity), प्रति-आइटम स्थिति, अनुरोध पहचान (request identity), आइडेंपोटेंट रिट्राय, ऑथराइजेशन और रिसोर्स सीमाएं, रिस्पॉन्स अनुकूलता और रिकवरी पर ध्यान केंद्रित करें। डिफॉल्ट व्यवहार बताएं, आंशिक सफलता को स्पष्ट रूप से कैसे चुना जाता है, और पूर्ण विफलता, आंशिक विफलता व अज्ञात परिणाम के बीच के अंतर को स्पष्ट करें।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

एक मजबूत उत्तर एटॉमिक प्रोसेसिंग, ऑप्ट-इन आंशिक सफलता या एसिंक्रोनस ऑपरेशन चुनने से पहले यह पूछता है कि क्या आइटम एक-दूसरे पर निर्भर हैं। यह केवल HTTP 200 और विफलता की गिनती नहीं लौटाता; यह प्रत्येक इनपुट को एक स्थिर परिणाम, एरर क्लास और पुन: प्रयास क्षमता (retryability) से मैप करता है। Google AIP-234 बताता है कि मौजूदा सिंक्रोनस बैच मेथड को आंशिक सफलता में बदलने से क्लाइंट्स टूट सकते हैं और यह प्रति-इंडेक्स विस्तृत विफलता स्थिति की अनुशंसा करता है; Stripe का आइडेंपोटेंसी मार्गदर्शन पुनः प्रयासों को समान मापदंडों (parameters) से बांधता है और पहले परिणाम को सुरक्षित रखता है। सीमाओं, ऑडिट और मॉनिटरिंग को भी कवर करें।

पूछने के लिए स्पष्टीकरण प्रश्न

क्या आइटमों के बीच क्रम (ordering) या ट्रांजैक्शनल निर्भरताएं हैं? क्या व्यवसाय को 'सभी-या-कुछ-नहीं' (all-or-nothing) होना चाहिए?
क्या प्रोसेसिंग से बाहरी साइड इफेक्ट्स उत्पन्न होते हैं, और क्या कोई आइडेंपोटेंसी कुंजी (idempotency key) रीप्ले को सुरक्षित बना सकती है?
क्या क्लाइंट को सिंक्रोनस परिणाम की आवश्यकता है, या क्या वह एक ऑपरेशन प्राप्त करके प्रगति को पोल (poll) या सब्सक्राइब कर सकता है?
बैच सीमा, बॉडी-साइज़, टाइमआउट, टेनेंट कोटा और निष्पक्षता (fairness) की आवश्यकताएं क्या हैं?
कौन सी त्रुटियां पुनः प्रयास योग्य (retryable) हैं, किनमें इनपुट परिवर्तन की आवश्यकता है, और किसी अज्ञात परिणाम को कैसे क्वेरी किया जा सकता है?

30-सेकंड का उत्तर ढांचा (Framework)

"मैं एटॉमिक बैचों को आंशिक-सफलता वाले बैचों से अलग करूंगा और अधिक सुरक्षित व्यवहार को डिफॉल्ट बनाऊंगा; आंशिक सफलता केवल तभी सक्षम होती है जब क्लाइंट ऑप्ट-इन करता है और व्यवसाय इसकी अनुमति देता है। प्रत्येक इनपुट को एक स्थिर इंडेक्स या क्लाइंट रिक्वेस्ट आईडी मिलती है, जबकि सर्वर बैच-स्तर और आइटम-स्तर की आइडेंपोटेंसी स्थिति, परिणाम और एरर क्लास रिकॉर्ड करता है। सिंक्रोनस कार्य सीमित होता है; बड़ा कार्य एक ऐसा ऑपरेशन बनाता है जो शार्ड्स (shards) में चलता है और प्रगति को प्रदर्शित करता है। रिस्पॉन्स सफलता, स्थायी विफलता, क्षणिक विफलता और अज्ञात स्थिति में अंतर करता है, और पुनः प्रयास उसी आइटम कुंजी का पुन: उपयोग करते हैं। मैं इस डिज़ाइन को रेट लिमिट्स, ऑडिट रिकॉर्ड्स, मेट्रिक्स और फॉल्ट इंजेक्शन के साथ सत्यापित करूंगा ताकि यह साबित हो सके कि साइड इफेक्ट्स न तो डुप्लिकेट होते हैं और न ही खोते हैं।"

चरण-दर-चरण उत्तर

चरण 1: एटॉमिसीटी मॉडल चुनें

यदि आइटम एक अविभाज्य व्यावसायिक इनवेरिएंट साझा करते हैं, जैसे कि ट्रांसफर के दोनों पक्षों का एक साथ सफल होना, तो एटॉमिक बैच ट्रांजैक्शन का उपयोग करें या बैच इंटरफ़ेस को अस्वीकार करें। यदि आइटम स्वतंत्र हैं, तो आंशिक सफलता पर विचार करें। मॉडल को "सर्वश्रेष्ठ प्रयास" (best effort) के पीछे न छिपाएं; क्लाइंट को पता होना चाहिए कि सभी सफल हुए, सभी विफल रहे, कुछ पूरे हुए, या सर्वर परिणाम की पुष्टि नहीं कर सकता है।

चरण 2: रिक्वेस्ट और आइटम की पहचान परिभाषित करें

एक बैच आईडी, आइटम ऐरे और क्लाइंट द्वारा जनरेट की गई आइटम रिक्वेस्ट आईडी शामिल करें। एक आइटम आईडी अपने व्यावसायिक दायरे में स्थिर होती है। समान आईडी के साथ डुप्लिकेट सबमिशन में महत्वपूर्ण मापदंडों की तुलना की जानी चाहिए; अलग-अलग मापदंडों पर मूक अधिलेखन (silent overwrite) के बजाय एक विरोध (conflict) उत्पन्न होना चाहिए। एक बैच आईडी ट्रेसिंग का समर्थन करती है लेकिन आइटम आइडेंपोटेंसी का स्थान नहीं ले सकती क्योंकि आंशिक पुनः प्रयास में मूल बैच से केवल विफल आइटम शामिल हो सकते हैं।

चरण 3: सिंक्रोनस/एसिंक्रोनस सीमा निर्धारित करें

छोटे बैच कुल समय और संसाधन बजट के साथ, सिंक्रोनस रूप से अंतिम प्रति-आइटम परिणाम लौटा सकते हैं। बड़े बैच या बाहरी सिस्टम को कॉल करने वाले ऑपरेशन्स को एक ऑपरेशन आईडी लौटानी चाहिए, सीमित शार्ड्स में निष्पादित होना चाहिए, और प्रगति को बनाए रखना चाहिए। एक क्लाइंट पूर्ण, प्रोसेसिंग, पुनः प्रयास योग्य और स्थायी-विफलता की संख्या को क्वेरी करता है; डिस्कनेक्ट होने के बाद यह साइड इफेक्ट्स फिर से शुरू करने के बजाय स्थिति को क्वेरी करता है।

चरण 4: पार्स करने योग्य (parseable) रिस्पॉन्स डिज़ाइन करें

रिस्पॉन्स ऐसा होना चाहिए जिससे क्लाइंट इनपुट पहचान द्वारा परिणाम ढूंढ सके, भले ही सर्वर कार्यों के क्रम को बदल दे। एक स्थिर इंडेक्स और क्लाइंट आईडी का उपयोग करें; इसमें मशीन-पठनीय एरर कोड, पुनः प्रयास क्षमता, पुनः प्रयास पर संभावित स्थिति परिवर्तन, और एक सुरक्षित यूजर संदेश शामिल करें। उदाहरण के लिए:

json

{
  "batch_id": "b_123",
  "status": "PARTIAL",
  "results": [
    {"index": 0, "request_id": "r_0", "status": "SUCCEEDED"},
    {"index": 1, "request_id": "r_1", "status": "FAILED", "error": {"code": "VERSION_CONFLICT", "retryable": false}}
  ],
  "next_page_token": null
}

Google AIP-234 एसिंक्रोनस बैच अपडेट के लिए इनपुट इंडेक्स से विस्तृत स्थिति तक एक failed_requests मैप की सिफारिश करता है। यह क्लाइंट को रिक्वेस्ट-आईडी-टू-रिक्वेस्ट मैप बनाए रखने के लिए बाध्य करने से बचाता है और संवेदनशील रिक्वेस्ट बॉडीज को दोहराने (echoing) से बचाता है। यदि किसी मौजूदा सिंक्रोनस API को आंशिक-सफलता सिमेंटिक्स की आवश्यकता है, तो एक नया वर्जन प्रकाशित करें या एक स्पष्ट फ़ील्ड के साथ बातचीत (negotiate) करें ताकि पुराने क्लाइंट सफलता की स्थिति को प्रत्येक आइटम के पूर्ण होने के रूप में न समझें।

चरण 5: आइडेंपोटेंसी, पुनः प्रयास और अज्ञात परिणामों को संभालें

सर्वर साइड इफेक्ट्स शुरू होने से पहले किसी आइडेंपोटेंट परिणाम को सहेजे बिना अमान्य मापदंडों को अस्वीकार कर सकता है। एक बार निष्पादन शुरू होने के बाद, परिणाम या क्वेरी करने योग्य इन-प्रोग्रेस स्थिति को सहेजें। नेटवर्क टाइमआउट के बाद, क्लाइंट को अनुमान लगाकर पूरे बैच को नहीं दोहराना चाहिए; यह बैच और आइटम कुंजियों का पुन: उपयोग करता है, अज्ञात वस्तुओं को क्वेरी करता है, और केवल स्पष्ट रूप से पुनः प्रयास योग्य आइटमों का पुनः प्रयास करता है। क्षणिक त्रुटियों के लिए बैकऑफ़ और जिटर का उपयोग करें, स्थायी त्रुटियों के लिए इनपुट परिवर्तनों की आवश्यकता रखें, और जब पुन: उपयोग की गई कुंजी विभिन्न मापदंडों को ले जाती है तो एक विरोध (conflict) लौटाएं।

चरण 6: संसाधनों और क्रमबद्धता (ordering) को अलग करें

कार्य को सीमित शार्ड्स में विभाजित करें और प्रति टेनेंट, बैच और डिपेंडेंसी समवर्तीता (concurrency) को सीमित करें। एक टोपोलॉजी या स्पष्ट चरण द्वारा निर्भर आइटम निष्पादित करें; विफलता के तूफ़ान (failure storm) को रोकने के लिए एक साझा पुनः प्रयास बजट के साथ स्वतंत्र आइटम समानांतर में चलाएं। प्रत्येक आइटम से पहले ऑथराइजेशन और कोटा की जांच करें, ताकि एक बैच एंडपॉइंट सिंगल-आइटम API की नीति को बायपास न कर सके।

चरण 7: त्रुटि, रद्दीकरण और पुनर्प्राप्ति सिमेंटिक्स को परिभाषित करें

इनपुट वैलिडेशन, ऑथराइजेशन, वर्जन विरोध, कोटा, क्षणिक निर्भरता और अज्ञात-परिणाम त्रुटियों को वर्गीकृत करें। रद्दीकरण (cancellation) उन वस्तुओं को रोकता है जो शुरू नहीं हुई हैं; पूर्ण हो चुके साइड इफेक्ट्स को रोल बैक करने का नाटक नहीं किया जा सकता है। यदि व्यवसाय को रिवर्सल की आवश्यकता है, तो एक अलग मुआवजा ऑपरेशन (compensation operation) प्रदान करें। पृष्ठभूमि कार्यों, परिणामों और मूल अनुरोध को सुरक्षित रखें ताकि पुनरारंभ होने पर प्रत्येक आइटम को फिर से निष्पादित करने के बजाय आइटम की स्थिति से कार्य फिर से शुरू हो सके।

चरण 8: निरंतरता और परिचालन दृश्यता (observability) सत्यापित करें

सभी-सफल, सभी-विफल, मिश्रित परिणाम, डुप्लिकेट अनुरोध, पैरामीटर विरोध, टाइमआउट-फिर-क्वेरी, डिपेंडेंसी फ्लैपिंग, कैंसलेशन रेस और वर्कर रीस्टार्ट का परीक्षण करें। बैच की सफलता, प्रति-आइटम एरर क्लास, अज्ञात स्थितियां, पुनः प्रयास प्रवर्धन (retry amplification), कतार की आयु (queue age), प्रोसेसिंग विलंबता, कोटा अस्वीकृति और डुप्लिकेट सबमिशन की निगरानी करें। बैच, आइटम, कर्ता (actor), ऑथराइजेशन निर्णय और अंतिम परिणाम का ऑडिट करें ताकि सहायता कर्मचारी यह स्पष्ट रूप से समझा सकें कि कौन से आइटम पूरे हुए।

डिज़ाइन ट्रेड-ऑफ़ और सीमाएं

आंशिक सफलता अपने आप में अधिक उन्नत विकल्प नहीं है। यह उन स्वतंत्र वस्तुओं के लिए उपयुक्त है जिन्हें ग्राहक एक-एक करके ठीक कर सकते हैं; शेष राशि (balances), इन्वेंट्री और क्रॉस-रिसोर्स इनवेरिएंट्स एटॉमिसीटी या एक स्पष्ट वर्कफ़्लो के साथ अधिक सुरक्षित हैं। HTTP 207 Multi-Status कई रिसोर्स स्थितियों को ले जा सकता है, लेकिन RFC 4918 इसे WebDAV के लिए परिभाषित करता है। एक सामान्य JSON API को यह नहीं मान लेना चाहिए कि क्लाइंट केवल इसलिए आंशिक परिणाम समझ जाएंगे क्योंकि यह 207 लौटाता है। आइटम सिमेंटिक्स को एक स्थिर रिस्पॉन्स बॉडी में रखें और मौजूदा-क्लाइंट अनुकूलता को ध्यान में रखते हुए स्टेटस कोड चुनें।

आपको एटॉमिक बैच कब चुनना चाहिए?

एटॉमिसीटी तब चुनें जब किसी भी आइटम की विफलता समग्र स्थिति को अमान्य बनाती है या मुआवजा अस्वीकार्य है। एक ट्रांजैक्शन, प्रीफ़्लाइट या वर्कफ़्लो का उपयोग करें, यह स्वीकार करते हुए कि शार्ड किया गया कार्य और बाहरी साइड इफेक्ट्स एक डेटाबेस ट्रांजैक्शन साझा नहीं करते हैं; उन्हें रिज़र्व, कमिट और क्षतिपूर्ति चरणों की आवश्यकता हो सकती है।

आपको एक एसिंक्रोनस ऑपरेशन कब चुनना चाहिए?

जब अवधि अप्रत्याशित हो, बैच बड़ा हो, बाहरी कॉल शामिल हों, या क्लाइंट को कनेक्शन खुला नहीं रखना चाहिए, तब एक ऑपरेशन लौटाएं। इसकी स्थिति पुनः क्वेरी करने योग्य होनी चाहिए, और परिणाम पृष्ठांकित (paginated) होने चाहिए। प्रगति को केवल "स्वीकृत" (accepted) होने पर "पूर्ण" (completed) नहीं कहना चाहिए।

विफलता अभ्यास और विकास योजना

सीमित टेनेंट सेट के साथ पायलट करें, आइटम की स्थिति और पुनः प्रयास व्यवहार को रिकॉर्ड करें, और फिर बैच सीमा को धीरे-धीरे बढ़ाएं। आइटम 30 के सफल होने के बाद एक नेटवर्क ब्रेक, लगातार 503 लौटाने वाली डिपेंडेंसी, विभिन्न मापदंडों के साथ समान कुंजी, और एक ऑपरेशन-वर्कर रीस्टार्ट को इंजेक्ट करें। कोटा का विस्तार करें या आंशिक सफलता तभी सक्षम करें जब क्लाइंट अज्ञात परिणामों को क्वेरी कर सकें और सर्वर यह साबित कर दे कि वह साइड इफेक्ट्स को दोहराता नहीं है।

आप एक सिंक्रोनस API को आंशिक सफलता में कैसे विकसित करते हैं?

पुराने संस्करण के एटॉमिक सिमेंटिक्स को बनाए रखें और एक ऐसा संस्करण जोड़ें जो एक ऑपरेशन और प्रति-आइटम विफलताएं लौटाता हो। वैकल्पिक रूप से, एक स्पष्ट return_partial_success फ़ील्ड की आवश्यकता रखें और इसके अनुपस्थित होने पर पुराने व्यवहार को सुरक्षित रखें। स्टेटस कोड, रिस्पॉन्स फ़ील्ड, पुनः प्रयास नियम और अप्रचलन (deprecation) तिथियों का दस्तावेजीकरण करें ताकि क्लाइंट चुपचाप अपनी व्याख्या न बदलें।

आप क्लाइंट की शुद्धता का मूल्यांकन कैसे करते हैं?

देखें कि क्या क्लाइंट आइटम आईडी को सहेजते हैं, केवल पुनः प्रयास योग्य विफलताओं का पुनः प्रयास करते हैं, अज्ञात परिणामों को क्वेरी करते हैं, और डुप्लिकेट साइड इफेक्ट्स व अमान्य पुनः प्रयासों से बचते हैं। महत्वपूर्ण SDK में पार्सिंग और क्वेरी सहायक प्रदान करें, जबकि सर्वर अभी भी अज्ञात फ़ील्ड और डुप्लिकेट अनुरोधों को सहन करता है।

सामान्य गलतियाँ और अनुवर्ती प्रश्न

विफलता की गिनती के साथ HTTP 200 लौटाना

एक पुराना क्लाइंट आंशिक पूर्णता को पूर्ण मान सकता है, और उसे अभी भी यह पता नहीं चल पाएगा कि किन आइटमों का पुनः प्रयास करना है। रिस्पॉन्स में समग्र स्थिति, आइटम पहचान, एरर क्लास और अगली कार्रवाई की आवश्यकता होती है।

किसी भी विफलता पर पूरे बैच का पुनः प्रयास करना

यह उन साइड इफेक्ट्स को दोहरा सकता है जो पहले ही सफल हो चुके हैं। पहले बैच और आइटम की आइडेंपोटेंसी स्थिति को क्वेरी करें, केवल स्पष्ट क्षणिक विफलताओं का पुनः प्रयास करें, और पैरामीटर बदलने पर एक नई व्यावसायिक रिक्वेस्ट आईडी का उपयोग करें।

परिणामों का क्रम कैसे होना चाहिए?

परिणामों को पूरा होने के क्रम से नहीं, बल्कि इनपुट इंडेक्स या स्थिर रिक्वेस्ट आईडी द्वारा संबद्ध करें। जब परिणाम पृष्ठांकित (paginated) हों तो पहचान बनाए रखें ताकि क्लाइंट सुरक्षित रूप से पृष्ठों को मर्ज कर सके।

क्या एक आइटम के सफल होने और बैच के रद्द होने के बाद आप रोलबैक कर सकते हैं?

रद्दीकरण केवल उन वस्तुओं को प्रभावित करता है जो शुरू नहीं हुई हैं। पहले से किए गए बाहरी साइड इफेक्ट्स के लिए एक मुआवजा API या मैन्युअल प्रबंधन की आवश्यकता होती है; "बैच रद्द" होना रोलबैक की गारंटी नहीं है।

आप बैच एंडपॉइंट को ऑथराइजेशन को बायपास करने से कैसे रोकते हैं?

बैच स्तर पर टेनेंट और ऑपरेशन की अनुमति की जाँच करें, फिर प्रत्येक आइटम से पहले रिसोर्स स्वामित्व, संस्करण और फ़ील्ड अनुमतियों की पुनः जाँच करें। बैचिंग शेड्यूलिंग को बदलती है, ऑथराइजेशन के दायरे को नहीं।

आप अंतिम आंशिक विफलता की व्याख्या कैसे करते हैं?

एक ऑडिट योग्य बैच आईडी, आइटम आईडी, स्थिति, एरर कोड, पुनः प्रयास क्षमता और टाइमस्टैम्प प्रदान करें। सहायता टीम को एक सुरक्षित व्यावसायिक स्पष्टीकरण दें और इंजीनियरिंग निदान के लिए ट्रेस और डिपेंडेंसी त्रुटियों को बनाए रखें।