सिस्टम डिज़ाइन साक्षात्कार: आप LWS के साथ अनुमति-आधारित बाहरी स्टोरेज कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

एकाधिक ऍप्लिकेशन्स के लिए एक इंटरऑपरेबल बाहरी डेटा-स्टोरेज सेवा डिज़ाइन करें। क्लाइंट्स को स्टोरेज खोजना, रीड/राइट एक्सेस का अनुरोध करना, संसाधन बनाना और परिवर्तनों की सदस्यता (subscribe) लेना आना चाहिए। रिसोर्स मॉडलिंग, HTTP सेमेन्टिक्स, प्रमाणीकरण (authentication), समवर्तीता (concurrency), नोटिफिकेशन और रोलबैक की व्याख्या करें।

W3C Linked Web Storage Protocol 1.0 वर्तमान में एक वर्किंग ड्राफ्ट (Working Draft) है। इसका उद्देश्य ऍप्लिकेशन्स को बाहरी रूप से संग्रहीत डेटा तक सुरक्षित, अनुमति-आधारित, इंटरऑपरेबल पहुँच प्रदान करना है। यह विनिर्देश स्टोरेज और पैरेंट संसाधनों को खोजने के लिए Link संबंधों का उपयोग करता है, लिंकसेट (linksets) के माध्यम से मेटाडेटा प्रबंधित करता है, और मेटाडेटा अपडेट और रिसोर्स संचालन के बीच परमाणुता (atomicity) की आवश्यकता रखता है। यह प्रश्न ड्राफ्ट को एक स्थिर मानक माने बिना प्रोटोकॉल सीमाओं और विफलता प्रबंधन का परीक्षण करता है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता संसाधनों, अनुमतियों, पहचान, मेटाडेटा और नोटिफिकेशन्स के बीच अलगाव के साथ-साथ POST पुनः प्रयासों (retries), समवर्ती PATCH, 405/415 प्रतिक्रियाओं, कैशिंग और निरसन (revocation) के सही संचालन की जांच करता है। एक मजबूत उत्तर वर्किंग ड्राफ्ट की अनिश्चितता को स्वीकार करता है और परिनियोजन आवश्यकताओं के आधार पर OpenID Connect, SAML और सेल्फ-साइन्ड पहचान सुइट्स में से चयन करता है।

उत्तर देने से पहले स्पष्टीकरण प्रश्न

डेटा स्वामी, ऍप्लिकेशन और स्टोरेज सेवा का संचालन कौन करता है, और विश्वास की सीमाएँ (trust boundaries) कहाँ हैं?
किन परिचालनों की आवश्यकता है: पढ़ना (read), बनाना (create), अपडेट करना (update), हटाना (delete), साझा करना (sharing), या केवल-पढ़ने के लिए सदस्यता (read-only subscriptions)?
क्या अनुमतियाँ उपयोगकर्ता, एजेंट, रिसोर्स पाथ, क्रिया या समय सीमा द्वारा दी जाती हैं?
क्या क्रॉस-रीजन एक्सेस, ऑफ़लाइन उपयोग, ऑडिट, निरसन और इवेन्चुअल नोटिफिकेशन की आवश्यकता है?
क्या क्लाइंट Link डिस्कवरी, ETags, 405/415 प्रतिक्रियाओं और पुनः प्रयास डुप्लीकेशन निवारण को संभाल सकते हैं?

30-सेकंड उत्तर रूपरेखा

“मैं स्टोरेज, कंटेनर्स, डेटा संसाधनों, लिंकसेट, पहचान और ग्रांट्स को अलग-अलग मॉडल करूँगा। एक क्लाइंट Link संबंधों के माध्यम से स्टोरेज और उसके पैरेंट की खोज करता है, एक घोषित सुइट के साथ प्रमाणित करता है, और क्रिया, विषय (subject), लक्ष्य और बाधाओं वाला अनुरोध सबमिट करता है। क्रिएशन के लिए POST का उपयोग किया जाता है, लेकिन एक आइडम्पोटेंसी कुंजी या डिडुप्लीकेशन पुनः प्रयास के डुप्लिकेट्स को रोकता है; मेटाडेटा PATCH के लिए समवर्ती शर्त की आवश्यकता होती है और यह रिसोर्स ऑपरेशन के साथ परमाणु रूप से कमिट होता है। सेवा संघर्षों के लिए ETags, कैपेबिलिटी हेडर्स और संरचित त्रुटियों का उपयोग करती है, जबकि एक पुनः प्रयास योग्य कतार इवेन्चुअली कंसिस्टेंट नोटिफिकेशन डिलीवर करती है। प्रत्येक कैनरी निरसन, पुराने अनुमति संस्करणों और ऑडिट रोलबैक को बनाए रखती है।”

चरण-दर-चरण गहन उत्तर

1. रिसोर्स और डिस्कवरी मॉडल स्थापित करें

स्टोरेज, कंटेनर, डेटा रिसोर्स और लिंकसेट को अलग करें। GET या HEAD प्रतिक्रियाएँ Link संबंधों के माध्यम से स्टोरेज रूट, पैरेंट, प्रकार और लिंकसेट को उजागर करती हैं; क्लाइंट्स को URL संरचना को प्रोटोकॉल अनुबंध नहीं मानना चाहिए। एक स्टोरेज विवरण को सर्वर क्षमताओं और मीडिया प्रकारों का विज्ञापन करना चाहिए ताकि क्लाइंट PUT या किसी विशिष्ट PATCH को भेजने से पहले बातचीत (negotiate) कर सकें।

2. अनुमतियों को ऑडिट करने योग्य ग्रांट्स के रूप में मॉडल करें

एक ग्रांट में समनुदेशिती (assignee), क्रिया, लक्ष्य, बाधाएं, जारीकर्ता, वैधता और निरसन स्थिति शामिल होनी चाहिए। स्टोरेज सेवा कॉलर पहचान और ग्रांट संस्करण की जांच करती है, फिर कम से कम विशेषाधिकार (least-privilege) से पढ़ना, बनाना, अपडेट करना या हटाना लागू करती है। OpenID Connect, SAML, या सेल्फ-साइन्ड पहचान पहचान साबित कर सकती है, लेकिन प्रमाणीकरण और रिसोर्स प्राधिकरण अलग रहते हैं; सफल लॉगिन का अर्थ प्रत्येक संसाधन तक पहुँच नहीं है।

3. निर्माण, अपडेट और समवर्ती सेमेन्टिक्स को परिभाषित करें

विनिर्देश POST और सर्वर द्वारा सौंपे गए अंतिम URI के साथ एक संसाधन बनाता है, जो 201 और Location लौटाता है। POST आइडम्पोटेंट नहीं है, इसलिए पुनः प्रयासों के लिए एक विशिष्ट अनुरोध पहचानकर्ता या डिडुप्लीकेशन रिकॉर्ड की आवश्यकता होती है। लिंकसेट PATCH प्राथमिक मेटाडेटा अपडेट है; खोए हुए अपडेट को रोकने के लिए ETag, If-Match, या समकक्ष संस्करण जांच का उपयोग करें। असमर्थित विधि के लिए 405 और असमर्थित मीडिया प्रकार के लिए 415 लौटाएँ।

text

POST /alice/notes/ HTTP/2
Idempotency-Key: 7b3c...
Link: <https://www.w3.org/ns/lws#DataResource>; rel="type"
Content-Type: text/plain

meeting notes

4. रिसोर्स और मेटाडेटा को सुसंगत रखें

निर्माण, कंटेनर सदस्यता और आवश्यक सर्वर मेटाडेटा को परमाणु रूप से कमिट होना चाहिए; विफलता से बिना पैरेंट संबंध या लिंकसेट के कोई दृश्यमान संसाधन नहीं छूटना चाहिए। शार्ड्स के पार, स्थिति रिकॉर्ड करने के लिए ट्रांजेक्शन लॉग या आउटबॉक्स का उपयोग करें। रीड APIs नोटिफिकेशन क्रम से कमिट की सफलता का अनुमान लगाने के बजाय लंबित, कमिटेड या विफल स्थितियों को उजागर कर सकते हैं।

5. नोटिफिकेशन और कैपेबिलिटी नेगोशिएशन डिज़ाइन करें

परिवर्तन इवेंट्स को पुनः प्रयास योग्य आउटबॉक्स में लिखें, फिर उन्हें सब्सक्राइबर इनबॉक्स में डिलीवर करें। स्टोरेज, रिसोर्स, क्रिया और संस्करण शामिल करें; उपभोक्ता इवेंट ID द्वारा डिडुप्लिकेट करते हैं और वर्तमान स्थिति को सत्यापित करने के लिए GET का उपयोग करते हैं। रीप्ले या आवधिक समाधान के साथ खोए हुए नोटिफिकेशन्स को पुनर्प्राप्त करें, और डुप्लिकेट प्रोसेसिंग को आइडम्पोटेंट रखें। Prefer, Link, और मीडिया-प्रकार नेगोशिएशन क्लाइंट्स को यह मानने के बजाय कि प्रत्येक सर्वर एक ही PATCH या सब्सक्रिप्शन मॉडल का समर्थन करता है, क्षमताओं को वृद्धिशील रूप से अपनाने की अनुमति देते हैं।

6. प्रमाणीकरण, निरसन और रोलबैक को संभालें

प्रमाणीकरण डिज़ाइन में कुंजी रोटेशन, टोकन ऑडियंस, क्लॉक स्क्यू और निरसन पथ शामिल करें। अनुमति परिवर्तनों को संस्करणित ऑडिट लॉग में लिखें और प्राधिकरण जांच और कैश अमान्यीकरण के बाद निरसन को प्रभावी बनाएं। कम जोखिम वाले किरायेदारों पर पहले कैनरी रोलआउट करें, जिसमें 401/403, 405/415, संघर्ष दर, डुप्लिकेट निर्माण, नोटिफिकेशन लेटेंसी और ऑडिट पूर्णता का निरीक्षण किया जाए; विशेषाधिकार बढ़ने या अनाथ डेटा पर रोकें और पुरानी प्राधिकरण नीति को पुनर्स्थापित करें।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं स्टोरेज, कंटेनर, डेटा संसाधन, लिंकसेट, पहचान और ग्रांट्स को अलग करूँगा। क्लाइंट GET/HEAD Link संबंधों के माध्यम से स्टोरेज रूट, पैरेंट, प्रकार और लिंकसेट की खोज करते हैं, फिर लिखने से पहले क्षमताओं पर बातचीत करते हैं। एक ग्रांट में विषय, क्रिया, लक्ष्य, बाधाएं, वैधता और निरसन शामिल होते हैं; OpenID Connect, SAML, या सेल्फ-साइन्ड पहचान पहचान साबित करती है लेकिन रिसोर्स एक्सेस प्रदान नहीं करती है। POST 201 और Location लौटाता है; क्योंकि यह आइडम्पोटेंट नहीं है, क्लाइंट एक अद्वितीय अनुरोध ID या डिडुप्लीकेशन का उपयोग करते हैं। लिंकसेट PATCH खोए हुए समवर्ती अपडेट को रोकने के लिए ETag/If-Match का उपयोग करता है, और असमर्थित विधियाँ या मीडिया प्रकार 405/415 लौटाते हैं। निर्माण, सदस्यता और सर्वर मेटाडेटा परमाणु रूप से कमिट होते हैं। आउटबॉक्स इवेंट्स पुनः प्रयास योग्य इनबॉक्स में जाते हैं, और उपभोक्ता इवेंट ID द्वारा डिडुप्लिकेट करते हैं और GET के साथ समाधान करते हैं। कैनरी रोलआउट 401/403, संघर्ष, डुप्लिकेट, नोटिफिकेशन लेटेंसी और ऑडिट पूर्णता का निरीक्षण करता है; विशेषाधिकार वृद्धि, अनाथ संसाधन, या विफल रोलबैक रोलआउट को रोक देता है। चूंकि प्रोटोकॉल एक वर्किंग ड्राफ्ट है, इसलिए अंतिम प्रोटोकॉल और परीक्षण मैट्रिक्स संस्करणित होना चाहिए।

सामान्य गलतियाँ

URL पाथ को संपूर्ण प्रोटोकॉल अनुबंध मानना → डिस्कवरी और क्षमता नेगोशिएशन टूट जाता है → Link संबंधों, मीडिया प्रकारों और कैपेबिलिटी हेडर्स पर निर्भर रहें।
POST को बिना शर्त पुनः प्रयास करना → डुप्लिकेट संसाधन बन सकते हैं → आइडम्पोटेंसी कुंजियों, डिडुप्लीकेशन रिकॉर्ड और अंतिम-स्थिति रीड्स का उपयोग करें।
लॉगिन की जांच करना लेकिन प्राधिकरण की नहीं → पहचान का अर्थ लक्ष्य तक पहुंच नहीं है → विषय, क्रिया, लक्ष्य और बाधाओं का मूल्यांकन करें।
मेटाडेटा को रिसोर्स से अलग कमिट करना → अनाथ संसाधन या गलत लिंकसेट दिखाई देते हैं → एक परमाणु लेनदेन या पुनर्प्राप्त करने योग्य आउटबॉक्स का उपयोग करें।
यह मान लेना कि प्रत्येक सर्वर PUT/PATCH का समर्थन करता है → क्लाइंट्स कमजोर हो जाते हैं → क्षमताओं की खोज करें और 405/415 को संभालें।

अनुवर्ती प्रश्न और उत्तर

POST पुनः प्रयास केवल TCP या HTTP पर निर्भर क्यों नहीं हो सकते?

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

आप अनुमति कैश से निरसन अंतराल (revocation lag) से कैसे बचते हैं?

कम TTL वाले संस्करणित ग्रांट्स का उपयोग करें, ऑडिट राइट के बाद प्रभावित कैश को सक्रिय रूप से अमान्य करें, और महत्वपूर्ण राइट्स के लिए प्राधिकरण संस्करण की पुन: जांच करें।

आप खोए हुए नोटिफिकेशन्स से कैसे उबरते हैं?

इवेंट्स को आउटबॉक्स में बनाए रखें, डिलीवरी का पुनः प्रयास करें, उपभोक्ता कर्सर बनाए रखें, रिसोर्स संस्करण द्वारा समाधान करें, और आवश्यकता पड़ने पर इवेंट लॉग को रीप्ले करें।

लिंकसेट अपडेट परमाणु क्यों होने चाहिए?

यदि संसाधन सफल हो जाता है लेकिन सदस्यता या प्रकार मेटाडेटा नहीं होता है, तो डिस्कवरी, प्राधिकरण और कैश असंगत स्थिति का निरीक्षण करते हैं। परमाणु कमिट आधे-अधूरे बने संसाधन को दृश्यमान होने से रोकता है।

वर्किंग ड्राफ्ट के दौरान आप निवेश को कैसे नियंत्रित करते हैं?

एक पृथक एडेप्टर और संस्करणित परीक्षण मैट्रिक्स का उपयोग करें, केवल कम जोखिम वाले ट्रैफ़िक का परीक्षण करें, पुराने प्रोटोकॉल और माइग्रेशन पथ को बनाए रखें, और विनिर्देश और कार्यान्वयन रिपोर्ट स्थिर होने के बाद विस्तार करें।