प्रॉम्प्ट और दायरा
यह प्रश्न यह जांचता है कि क्या कोई बैकएंड इंजीनियर HTTP सीमा पर समवर्ती नियंत्रण (concurrency control) लागू कर सकता है। कैश वैलिडेशन और राइट प्रोटेक्शन के बीच का अंतर समझाएं, सर्वर एंटिटी टैग्स की तुलना कैसे करता है, यह कौन से स्टेटस कोड लौटाता है, और डेटाबेस राइट्स तथा रिस्पॉन्स हेडर कैसे संरेखित (aligned) रहते हैं।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
- क्या आप ETag, If-Match, और If-None-Match के अलग-अलग अर्थों को समझते हैं।
- क्या एक स्ट्रॉन्ग वैलिडेटर राइट्स को पुराने वर्ज़न से सुरक्षित रखता है।
- क्या 412, 428, और 409 की प्रीकंडीशन और बिज़नेस-कॉन्फ्लिक्ट सीमाएं स्पष्ट रूप से अलग हैं।
- क्या आप प्रॉक्सी कैश, रिट्राइज़, ऑथराइजेशन और रेप्लिकेट विजिबिलिटी का ध्यान रखते हैं।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
पुष्टि करें कि क्या अपडेट पूरे रिसोर्स को बदलते हैं या केवल कुछ फ़ील्ड्स को, क्या क्लाइंट्स को वर्ज़न भेजना अनिवार्य है, क्या ऑफलाइन एडिटिंग और मर्ज समर्थित हैं, क्या ETag पूर्ण रिप्रेजेंटेशन का प्रतिनिधित्व करता है या केवल किसी बिज़नेस वर्ज़न का, और क्या रीड्स और राइट्स कैश, लोड बैलेंसर या मल्टीपल डेटाबेस रेप्लिका से होकर गुजरते हैं।
30-सेकंड की उत्तर संरचना
प्रत्येक रिसोर्स रिप्रेजेंटेशन के साथ एक ETag लौटाएं। म्यूटेशन पर If-Match अनिवार्य करें, राइट बाउंड्री के भीतर वर्तमान वर्ज़न से इसकी तुलना करें, और मिसमैच होने पर 412 या आवश्यक प्रीकंडीशन गायब होने पर 428 लौटाएं। सफलता मिलने पर, वर्ज़न को बढ़ाएं और एक नया ETag लौटाएं। If-None-Match के साथ GET 304 लौटा सकता है, लेकिन कैश वैलिडेशन राइट्स की सुरक्षा नहीं करता है।
विस्तृत उत्तर
1. कैश वैलिडेशन को राइट प्रोटेक्शन से अलग रखें
If-None-Match GET कैश वैलिडेशन के लिए उपयोगी है: एक अपरिवर्तित रिप्रेजेंटेशन 304 उत्पन्न कर सकता है। If-Match के लिए आवश्यक है कि वर्तमान रिप्रेजेंटेशन मेल खाए और यह PUT, PATCH या DELETE पर सामान्य है। कैश हिट वर्तमान रिसोर्स को ओवरराइट करने की अनुमति नहीं देता है; तुलना की दिशा और विफलता का व्यवहार अलग होता है।
2. ऐसा ETag चुनें जिसकी तुलना करना सुरक्षित हो
राइट प्रोटेक्शन के लिए एक स्ट्रॉन्ग ETag का उपयोग करें ताकि बाइट्स या परिभाषित वर्ज़न बिल्कुल सटीक रूप से मेल खाएं। वीक ETag सिमेंटिक रूप से समान कैश रिप्रेजेंटेशन के लिए उपयुक्त होते हैं और इनका उपयोग सटीक अपडेट्स को ऑथराइज करने के लिए नहीं किया जाना चाहिए। टैग को किसी आंतरिक अनुक्रम या संवेदनशील डेटा को उजागर नहीं करना चाहिए; ऑथराइजेशन फ़िल्टरिंग लागू करने के बाद, इसे एक अप्रत्याशित साल्ट (unpredictable salt) के साथ कैनोनिकल रिप्रेजेंटेशन और वर्ज़न से प्राप्त करें।
3. तुलना और अपडेट को एक ही बाउंड्री में रखें
वर्तमान वर्ज़न को पढ़ें, If-Match की तुलना करें, और एक ही कंडीशनल डेटाबेस राइट जैसे कि UPDATE ... WHERE id = ? AND version = ? में अपडेट करें। शून्य प्रभावित पंक्तियों का अर्थ 412 है; एक सफल अपडेट वर्ज़न को बढ़ाता है और नया ETag उत्पन्न करता है। एप्लिकेशन कोड में क्वेरी करके उसके बाद अनकंडीशनल राइट निष्पादित न करें।
4. विफलता प्रतिक्रियाएं और पुनः प्रयास पथ डिज़ाइन करें
आवश्यक प्रीकंडीशन अनुपस्थित होने पर 428, ETag मेल न खाने पर 412, और एक अलग बिज़नेस-स्टेट कॉन्फ्लिक्ट के लिए 409 लौटाएं। वर्तमान रिप्रेजेंटेशन या पुनः प्राप्त करने का संकेत शामिल करें, लेकिन क्लाइंट के लिए चुपचाप ओवरराइट न करें। 412 के बाद, क्लाइंट को फिर से GET करना चाहिए, एक डिफ (diff) दिखाना चाहिए, या एक स्पष्ट फ़ील्ड मर्ज लागू करना चाहिए और नए ETag के साथ पुनः प्रयास करना चाहिए; स्वचालित पुनः प्रयासों के लिए सीमित प्रयास और स्पष्ट आइडमपोटेंसी की आवश्यकता होती है।
5. कैश, रेप्लिका और संचालन संभालें
ETag बनाने वाले रीड को नवीनतम राइट देखना चाहिए, या सिस्टम को एक सीमित रीड-आफ्टर-राइट देरी को परिभाषित करना चाहिए। प्रॉक्सी को संवेदनशील रिसोर्सेस के लिए उपयुक्त कैश नियंत्रण के साथ ETag, If-Match और If-None-Match को सही ढंग से अग्रेषित (forward) करना चाहिए। पुराने रिप्रेजेंटेशन या लैगिंग रेप्लिका का उपयोग करने वाले क्लाइंट्स का पता लगाने के लिए रिक्वेस्ट आईडी, पुराने और नए वर्ज़न, परिणाम और कॉन्फ्लिक्ट दर को लॉग करें।
एक मजबूत उत्तर का उदाहरण
मैं प्रत्येक GET के साथ एक कैनोनिकल रिप्रेजेंटेशन और वर्ज़न से प्राप्त स्ट्रॉन्ग ETag लौटाऊंगा। PUT, PATCH और DELETE के लिए If-Match की आवश्यकता होती है; डेटाबेस एक वर्ज़न-कंडीशनल अपडेट करता है, और किसी भी पंक्ति के मेल न खाने पर 412 लौटाता है। अनुपलब्ध प्रीकंडीशन इंटरफ़ेस नीति का पालन करती हैं और 428 लौटाती हैं, जबकि सफलता वर्ज़न को बढ़ाती है और नया ETag लौटाती है। मेल खाने वाले If-None-Match के साथ GET केवल कैश बचत के लिए 304 लौटाता है। 412 के बाद, क्लाइंट दोबारा पढ़ता है, डिफ दिखाता है या एक स्पष्ट फ़ील्ड मर्ज करता है, और नए टैग के साथ पुनः प्रयास करता है। रेप्लिका में रीड्स को वर्तमान वर्ज़न देखना चाहिए, और प्रॉक्सी को कंडीशनल हेडर अग्रेषित करने चाहिए। कॉन्फ्लिक्ट्स, पुराने-वर्ज़न के अनुरोधों और रेप्लिका लैग की निगरानी करें।
सामान्य गलतियाँ
- केवल क्लाइंट टाइमस्टैम्प की तुलना करना और क्लॉक स्क्यू या रिप्रेजेंटेशन के अंतर को अनदेखा करना।
- सटीक राइट को ऑथराइज़ करने के लिए वीक ETag का उपयोग करना।
- पहले वर्ज़न को क्वेरी करना और फिर बिना किसी शर्त के लिखना, जिससे रेस कंडीशन छूट जाती है।
- 412, 409 और 428 को एक सामान्य त्रुटि मानना जो क्लाइंट्स को कोई अगला कदम नहीं देती है।
- सर्वर को चुपचाप किसी कॉन्फ्लिक्ट को ओवरराइट करने देना और क्लाइंट के संपादन को खो देना।
- कैश और रेप्लिका विजिबिलिटी पर विचार किए बिना केवल एप्लिकेशन नोड्स पर टैग जनरेट करना।
फॉलो-अप प्रश्न
क्या ETag एक डेटाबेस ऑटो-इंक्रीमेंट वर्ज़न हो सकता है?
यह एक आंतरिक इनपुट हो सकता है, लेकिन HTTP के लिए मान को एन्कोड करें और संवेदनशील व्यावसायिक जानकारी को उजागर करने से बचें। यदि रिप्रेजेंटेशन फ़ील्ड फ़िल्टरिंग या ऑथराइजेशन के साथ बदलता है, तो उस रिप्रेजेंटेशन बाउंड्री पर टैग जनरेट करें।
क्या दो गैर-अतिव्यापी (non-overlapping) PATCH फ़ील्ड्स को स्वचालित रूप से मर्ज किया जा सकता है?
एक स्पष्ट फ़ील्ड-स्तरीय मर्ज प्रोटोकॉल प्रदान करें, लेकिन फिर भी सत्यापित करें कि क्लाइंट ने किस ETag का उपयोग किया था। मर्ज और गैर-मर्ज नियमों को प्रकाशित करें और निर्णय का ऑडिट करें; अलग-अलग फ़ील्ड होने से हर बिज़नेस कॉन्फ्लिक्ट को अनदेखा करना सुरक्षित नहीं हो जाता।
केवल 409 ही क्यों न लौटाएं?
412 का अर्थ है कि If-Match-प्रकार की प्रीकंडीशन विफल रही, 428 क्लाइंट से एक प्रदान करने के लिए कहता है, और 409 वर्तमान रिसोर्स स्थिति या व्यावसायिक संचालन के साथ एक अलग कॉन्फ्लिक्ट का वर्णन करता है। यह अंतर क्लाइंट को बताता है कि क्या दोबारा प्राप्त करना है, हेडर जोड़ना है, या कार्रवाई को बदलना है।
आप CDN के माध्यम से पुराने राइट्स से कैसे बचते हैं?
म्यूटेशन को आधिकारिक मूल (authoritative origin) पर रूट करें और रीड्स के लिए कैश का उपयोग करें। विनिर्देश के अनुसार कंडीशनल हेडर अग्रेषित करें, सफल अपडेट के बाद प्रभावित प्रविष्टियों को अमान्य करें या पुरानेपन को सीमित करें, और मूल-वर्ज़न बनाम एज-टैग अंतरों की निगरानी करें।