प्रॉम्प्ट और संदर्भ
एक API वर्ज़न वैलिडेटर के साथ एक डॉक्यूमेंट सर्व करती है। कई क्लाइंट इसे एक साथ पढ़ और एडिट कर सकते हैं, और आवश्यकता यह है कि API को पुनः प्रयास योग्य (retryable) और अवलोकनीय (observable) रखते हुए पुराने राइट्स (stale writes) को अस्वीकार किया जाए।
इंटरव्यूअर क्या टेस्ट करता है
- रिप्रेजेंटेशन कैशिंग और राइट प्रीकंडीशन्स में अंतर करना।
- एक स्ट्रॉन्ग ETag चुनना और म्यूटेशन मेथड्स पर
If-Matchलागू करना। - पुराने वर्ज़न पर 412 लौटाना और एक सुरक्षित क्लाइंट रिकवरी पाथ परिभाषित करना।
उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
- क्या ETag सटीक संग्रहीत रिप्रेजेंटेशन को दर्शाता है या केवल एक कमज़ोर सिमेंटिक वर्ज़न को?
- किन मेथड्स के लिए प्रीकंडीशन आवश्यक है: PUT, PATCH, DELETE, या सभी राइट्स?
- क्या क्लाइंट को फ़ील्ड्स को स्वचालित रूप से मर्ज करना चाहिए, या किसी इंसान को टकराव (conflicts) हल करना होगा?
- क्या पुनः प्रयास लोड-बैलेंस्ड API और सिंगल ट्रांज़ैक्शनल डेटास्टोर के माध्यम से भेजे जाते हैं?
30-सेकंड उत्तर रूपरेखा
मैं प्रत्येक एडिट करने योग्य रिप्रेजेंटेशन के साथ एक स्ट्रॉन्ग ETag लौटाऊँगा। क्लाइंट PUT, PATCH, या DELETE पर If-Match में वह मान भेजता है। सर्वर अपडेट के समान ट्रांज़ैक्शन के अंदर इसकी तुलना करता है; बेमेल होने पर म्यूटेशन लागू किए बिना 412 लौटाया जाता है। रिस्पॉन्स में वर्तमान रिप्रेजेंटेशन या रिफ़ेच सिग्नल शामिल होना चाहिए, जबकि मेट्रिक्स टकरावों और अनुपस्थित प्रीकंडीशन्स को ट्रैक करते हैं। इसके बाद क्लाइंट पुनः प्राप्त (refetch) करता है, सोच-समझकर मर्ज करता है, और नए ETag के साथ पुनः प्रयास करता है।
चरण-दर-चरण विस्तृत विश्लेषण
1. वैलिडेटर जारी करना
GET पर, डॉक्यूमेंट और कैनोनिकल स्टोर्ड वर्ज़न से प्राप्त ETag लौटाएँ। डेटाबेस रिवीज़न नंबर एक बड़े पेलोड को हैश करने की तुलना में सरल हो सकता है, बशर्ते एडिट से संबंधित रिप्रेजेंटेशन बदलते ही वैल्यू बदल जाए। If-Match के लिए स्ट्रॉन्ग वैलिडेटर का उपयोग करें; कमज़ोर वैलिडेटर सटीक राइट स्टेट की सुरक्षा के लिए अनुपयुक्त होते हैं।
2. प्रीकंडीशन को एटॉमिक रूप से लागू करना
अपडेट को अपेक्षित वर्ज़न की जाँच करनी चाहिए और एक ही सशर्त ऑपरेशन के रूप में नया वर्ज़न लिखना चाहिए। वैचारिक रूप से:
UPDATE documents
SET body = :new_body, version = version + 1
WHERE id = :id AND version = :expected_version;यदि प्रभावित पंक्तियों (affected-row) की संख्या शून्य है, तो 412 लौटाएँ और कोई साइड इफेक्ट न करें। एप्लिकेशन मेमोरी में ETag की जाँच करना और बाद में लिखना, जाँच और कमिट के बीच एक रेस कंडीशन पैदा करता है।
3. 412 को अन्य विफलताओं से अलग करना
412 का अर्थ है कि दी गई प्रीकंडीशन गलत है; यह एक कॉनकरेंसी टकराव है, न कि विकृत JSON और न ही प्रमाणीकरण विफलता। अमान्य अनुरोध संरचना के लिए 400, ऑथराइज़ेशन के लिए 401 या 403, और API नीति के तहत संसाधन अनुपलब्ध होने पर 404 लौटाएँ। यह अंतर क्लाइंट्स को रीफ़ेच-और-मर्ज बनाम उपयोगकर्ता सुधार चुनने की अनुमति देता है।
4. क्लाइंट रिकवरी डिज़ाइन करना
412 के बाद, वर्तमान डॉक्यूमेंट प्राप्त करें और परस्पर विरोधी फ़ील्ड या diff दिखाएं। स्वचालित मर्ज केवल तभी सुरक्षित होता है जब फ़ील्ड-स्तरीय सेमांटिक्स और ऑथराइज़ेशन नियम इसे सुरक्षित बनाते हैं। पुनः प्रयास में नए लौटाए गए ETag का उपयोग होना चाहिए और संसाधन स्तर पर इडेम्पोटेंट (idempotent) रहना चाहिए; पुराने अनुरोध को कभी भी आँख मूंदकर दोबारा न चलाएँ।
5. कैश और रेप्लिका को सुसंगत रखना
राइट पाथ के लिए दृश्यमान कमिटेड स्टेट से वैलिडेटर जनरेट करें। लैगिंग रेप्लिका से रीड करने पर पुराना ETag मिल सकता है और टाले जा सकने वाले टकराव हो सकते हैं, जबकि दूसरे नोड पर रूट किए गए राइट को अभी भी प्राइमरी ट्रांज़ैक्शन में वर्ज़न को लागू करना चाहिए। टकराव दर, अनुपस्थित-If-Match दर, और पुनः प्रयास सफलता मेट्रिक्स उत्सर्जित करें।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं प्रत्येक एडिट करने योग्य डॉक्यूमेंट के लिए एक स्ट्रॉन्ग ETag लौटाऊँगा और म्यूटेशन पर If-Match की आवश्यकता रखूँगा। सर्वर सशर्त वर्ज़न अपडेट का उपयोग करके पंक्ति को अपडेट करने वाले उसी ट्रांज़ैक्शन में टैग की तुलना करेगा। यदि कोई पंक्ति मेल नहीं खाती है, तो यह 412 लौटाता है और कोई साइड इफेक्ट लागू नहीं करता है। क्लाइंट रीफ़ेच करता है, एक diff प्रस्तुत करता है या एक संकीर्ण रूप से परिभाषित मर्ज करता है, फिर नए ETag के साथ पुनः प्रयास करता है। मैं 412 को वैलिडेशन और ऑथराइज़ेशन त्रुटियों से अलग करूँगा, और पुराने-रीड, टकराव, और पुनः प्रयास-सफलता दरों की निगरानी करूँगा।”
सामान्य गलतियाँ
- ETag की जाँच करना, फिर अलग ऑपरेशनों में अपडेट करना → एक रेस बनी रहती है → वर्ज़न प्रेडिकेट और राइट को एटॉमिक रूप से निष्पादित करें।
- सटीक राइट्स के लिए कमज़ोर वैलिडेटर का उपयोग करना → सेमांटिक रूप से समान सामग्री की गलत तुलना हो सकती है → एक स्ट्रॉन्ग वैलिडेटर का उपयोग करें।
- प्रत्येक पुराने राइट के लिए 409 लौटाना → क्लाइंट प्रोटोकॉल प्रीकंडीशन्स में अंतर नहीं कर सकते → विफल
If-Matchस्थिति के लिए 412 का उपयोग करें। - पुराने पेलोड को आँख मूंदकर पुनः प्रयास करना → पहले एडिटर के परिवर्तन खो सकते हैं → रीफ़ेच करें, जानबूझकर मर्ज करें, और नए टैग के साथ पुनः प्रयास करें।
अनुवर्ती प्रश्न और उत्तर
क्या ETag केवल कैशिंग के लिए है?
नहीं। If-None-Match आमतौर पर कैश वैलिडेशन को सक्षम करता है, जबकि If-Match एक राइट को वर्तमान रिप्रेजेंटेशन पर सशर्त बनाता है। यदि इसकी तुलना की शक्ति और जनरेशन नीति सही है तो वही वैलिडेटर दोनों भूमिकाएँ निभा सकता है।
क्या होगा यदि क्लाइंट If-Match छोड़ देता है?
ऑप्टिमिस्टिक कॉनकरेंसी की आवश्यकता वाले संसाधनों के लिए, प्रलेखित प्रीकंडीशन-आवश्यक रिस्पॉन्स या स्पष्ट 400 नीति के साथ म्यूटेशन को अस्वीकार करें। बिना शर्त वाले राइट को चुपचाप स्वीकार करने से लॉस्ट अपडेट्स फिर से शुरू हो जाते हैं; नीति सभी मेथड्स में सुसंगत होनी चाहिए।
क्या सर्वर को 412 रिस्पॉन्स में नवीनतम डॉक्यूमेंट लौटाना चाहिए?
यदि ऑथराइज़ेशन और पेलोड आकार अनुमति देते हैं, तो यह लौटा सकता है, लेकिन कॉन्ट्रैक्ट में अभी भी रीफ़ेच या स्पष्ट टकराव समाधान की आवश्यकता होनी चाहिए। डेटा लौटाने से क्लाइंट को नवीनतम वैलिडेटर का उपयोग किए बिना इसे ओवरराइट करने का अधिकार नहीं मिल जाता है।