प्रॉम्प्ट और संदर्भ
यह सिस्टम-डिज़ाइन प्रॉम्प्ट प्लेटफ़ॉर्म, बैकएंड और SaaS इन्फ्रास्ट्रक्चर भूमिकाओं के लिए उपयुक्त है। एक बिलिंग सिस्टम प्लान और भुगतान इवेंट्स उत्सर्जित करता है; उत्पाद सेवाओं को can tenant T use feature F for subject U? जैसे ऑथराइजेशन निर्णय की आवश्यकता होती है। 50,000 टेनेंट्स, 10 मिलियन सब्जेक्ट्स, पीक पर 100,000 निर्णय अनुरोध प्रति सेकंड और 99.99% मासिक उपलब्धता लक्ष्य मान लें। रद्द या निलंबित किया गया एंटाइटेलमेंट अनिश्चित काल तक उपयोग योग्य नहीं रहना चाहिए, जबकि बिलिंग आउटेज से प्रत्येक रीड पाथ ठप नहीं होना चाहिए।
साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है
- क्या आप व्यावसायिक सत्य के स्रोत के रूप में बिलिंग को मूल्यांकित एंटाइटेलमेंट स्नैपशॉट से अलग कर सकते हैं?
- क्या आप टेनेंट और सब्जेक्ट आइसोलेशन, और प्लान, ऐड-ऑन, ट्रायल और डिनाई नियमों के बीच प्राथमिकता को परिभाषित करते हैं?
- क्या आप इवेंट ऑर्डरिंग, कैश स्टेलनेस, रिवोकेशन लेटेंसी, और फेल-ओपन बनाम फेल-क्लोज़्ड निर्णयों के बारे में तर्क कर सकते हैं?
- क्या आप एक वर्जन्ड API, ऑडिट ट्रेल, ऑब्ज़र्वेबिलिटी और एक रीप्ले करने योग्य रिकवरी पाथ प्रदान करते हैं?
पूछे जाने वाले स्पष्टीकरण प्रश्न
पूछें कि क्या निर्णय प्रति टेनेंट, उपयोगकर्ता, सेवा खाते या सीट के अनुसार हैं; क्या किसी फ़ीचर को सबसेट के लिए सक्षम किया जा सकता है; रद्दीकरण को कितनी जल्दी एक्सेस रिवोक करना चाहिए; क्या उपयोग कोटा निर्णय का हिस्सा हैं; और क्या प्रत्येक निर्णय के लिए एक व्याख्या योग्य कारण की आवश्यकता है। पुष्टि करें कि क्या बिलिंग इवेंट्स at-least-once हैं और क्रम से बाहर आ सकते हैं। ये उत्तर स्नैपशॉट स्कीमा, इवेंट हैंडलिंग, कैश TTL और फेलओवर नीति को बदलते हैं।
30-सेकंड उत्तर फ़्रेमवर्क
मैं बिलिंग को आधिकारिक स्रोत के रूप में रखूँगा और टेनेंट, सब्जेक्ट स्कोप, फ़ीचर और वर्ज़न द्वारा की (keyed) किया गया एक एंटाइटेलमेंट प्रोजेक्शन बनाऊँगा। एक राइट पाथ क्रमबद्ध या डुप्लिकेट-मुक्त सब्सक्रिप्शन इवेंट्स का उपभोग करता है, एक नया स्नैपशॉट गणना करता है, और एक इनवैलिडेशन प्रकाशित करता है। एक रीड API स्पष्ट प्राथमिकता के साथ स्नैपशॉट का मूल्यांकन करता है और allow, deny, कारण और वर्ज़न लौटाता है। क्षेत्रीय कैश अत्यधिक लोड वाले रीड्स को सर्व करते हैं, लेकिन एक रिवोकेशन टोकन या वर्ज़न फेंस स्टेल एक्सेस को सीमित करता है। फेल-ओपन केवल कम जोखिम वाले फ़ीचर्स के लिए अनुमत है; सशुल्क या सुरक्षा-संवेदनशील फ़ीचर्स फेल क्लोज़ होते हैं और एक रिकवरी पाथ प्रदर्शित करते हैं। प्रत्येक परिवर्तन और निर्णय ऑडिट योग्य है।
चरण-दर-चरण गहन विश्लेषण
- कॉन्ट्रैक्ट परिभाषित करें।
Evaluate(tenant_id, subject_id, feature, context)एक निर्णय, कारण कोड, स्नैपशॉट वर्ज़न और समाप्ति समय लौटाता है। संदर्भ में प्लान, क्षेत्र, सीट या रोलआउट विशेषताएँ शामिल हो सकती हैं; OpenFeature को एक अद्वितीय लक्ष्यीकरण कुंजी की आवश्यकता होती है और यह कस्टम फ़ील्ड्स का समर्थन करता है, इसलिए बिलिंग स्थिति के साथ एकल फ्री-फॉर्म स्ट्रिंग को ओवरलोड न करें। - अपरिवर्तनीय (Immutable) ग्रांट्स को मॉडल करें। सब्सक्रिप्शन उत्पादों, ऐड-ऑन, ट्रायल, सीटों, प्रभावी और समाप्ति समय, और स्पष्ट अस्वीकरणों (explicit denies) को वर्जन्ड तथ्यों के रूप में संग्रहीत करें। प्रोजेक्शन रिज़ॉल्व किए गए फ़ीचर सेट और सोर्स फैक्ट IDs को संग्रहीत करता है। सस्पेंशन या अनुपालन से एक डिनाई सामान्य ग्रांट को ओवरराइड करता है; एक समय-सीमा वाला ट्रायल इतिहास को बदले बिना समाप्त हो जाता है।
- प्रोपेगेशन पाथ का निर्माण करें। बिलिंग टेनेंट, सब्सक्रिप्शन वर्ज़न, इवेंट ID और प्रभावी समय के साथ एक इवेंट उत्सर्जित करती है। एक इनबॉक्स इवेंट IDs को डिडुप्लिकेट करता है, पुराने वर्ज़न को अस्वीकार करता है, और फैक्ट व प्रोजेक्शन को ट्रांज़ैक्शनल रूप से लिखता है। एक आउटबॉक्स
entitlement_version_changedप्रकाशित करता है; उपभोक्ता टेनेंट और फ़ीचर द्वारा अमान्य करते हैं। तथ्यों को रीप्ले करने से डेटा करप्शन के बाद प्रोजेक्शन का पुनर्निर्माण होता है। - रीड्स को सर्व करें। एक स्टेटलेस इवैल्यूएशन API स्थानीय कैश या क्षेत्रीय स्टोर को पढ़ता है। कैश कुंजियों में टेनेंट, सब्जेक्ट स्कोप, फ़ीचर और पॉलिसी वर्ज़न शामिल होते हैं। कैश प्रविष्टियों में प्रोजेक्शन वर्ज़न और समाप्ति समय होता है। यदि कोई अनुरोध कैश की तुलना में नया वर्ज़न फेंस प्रस्तुत करता है, तो निर्णय लेने से पहले आधिकारिक क्षेत्रीय स्टोर को पढ़ें।
- जोखिम के अनुसार कंसिस्टेंसी चुनें। एक मापा गया रिवोकेशन SLO सेट करें, जैसे कि सामान्य रद्दीकरण के लिए 60 सेकंड और धोखाधड़ी या सुरक्षा निलंबन के लिए लगभग तत्काल फेंसिंग। एक डिनाई फेंस को अत्यधिक सुलभ स्टोर में प्रकाशित करें; सेवाएँ उस फेंस से पुराने कैश्ड अलाउ को अस्वीकार करती हैं। सिंक्रोनस जांच की लागत चुकाए बिना शून्य स्टेल रीड्स का वादा न करें।
- विफलताओं और स्केल को संभालें। टेनेंट-वार क्रम बनाए रखने के लिए इवेंट्स को टेनेंट द्वारा विभाजित (partition) करें, टेनेंट हैश द्वारा प्रोजेक्शन को शार्ड करें, और हॉट टेनेंट्स को अलग रखें। बिलिंग में देरी होने पर, अंतिम-लागू वर्ज़न प्रदर्शित करें और अलर्ट भेजें। कैश या क्षेत्रीय-स्टोर विफलता पर, केवल कम जोखिम वाले फ़ीचर्स के लिए एक सीमित स्टेल विंडो का उपयोग करें; चुपचाप एक्सेस देने के बजाय उच्च जोखिम वाले फ़ीचर्स के लिए टाइप्ड डिपेंडेंसी एरर लौटाएं।
- ऑडिट और सत्यापन करें। रिकॉर्ड करें कि किसने प्लान बदला, किस इवेंट वर्ज़न ने प्रोजेक्शन तैयार किया, और निर्णय क्यों लिया गया। इवेंट लैग, प्रोजेक्शन आयु, कैश हिट दर, स्टेल-अलाउ ब्लॉक, निर्णय लेटेंसी, और क्रॉस-टेनेंट ऑथराइजेशन विफलताओं को मापें। आउट-ऑफ-ऑर्डर इवेंट्स, डुप्लिकेट डिलीवरी, क्लॉक स्क्यू, अनुरोध के दौरान रद्दीकरण, टेनेंट माइग्रेशन, और एक खाली प्रोजेक्शन से रीप्ले का परीक्षण करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं व्यावसायिक सत्य को एक वर्जन्ड एंटाइटेलमेंट प्रोजेक्शन से अलग रखूँगा। बिलिंग इवेंट्स में एक इवेंट ID, टेनेंट, सब्सक्रिप्शन वर्ज़न, प्रभावी समय और बदले गए उत्पाद होते हैं। एक इनबॉक्स पुराने वर्ज़न को डिडुप्लिकेट और अस्वीकार करता है, फिर ट्रांज़ैक्शनल रूप से तथ्यों, रिज़ॉल्व किए गए फ़ीचर स्नैपशॉट और एक आउटबॉक्स नोटिफिकेशन को लिखता है। इवैल्यूएशन API allow या deny, कारण, प्रोजेक्शन वर्ज़न और समाप्ति समय लौटाता है। एक कैश कुंजी में टेनेंट और सब्जेक्ट स्कोप शामिल होता है ताकि एक ग्राहक दूसरे ग्राहक का निर्णय न पढ़ सके।
मुख्य ट्रेड-ऑफ रिवोकेशन है। मैं एक 60-सेकंड का सामान्य रद्दीकरण SLO सेट करूँगा और धोखाधड़ी या सुरक्षा निलंबन के लिए एक डिनाई फेंस प्रकाशित करूँगा। प्रत्येक कैश्ड अलाउ में एक प्रोजेक्शन वर्ज़न होता है; एक नया फेंस क्षेत्रीय-स्टोर रीड को बाध्य करता है। कम जोखिम वाले UI फ़ीचर्स स्टोर आउटेज के दौरान सीमित स्टेल विंडो का उपयोग कर सकते हैं, जबकि सशुल्क डेटा निर्यात या सुरक्षा नियंत्रण एक टाइप्ड डिपेंडेंसी एरर के साथ फेल क्लोज़ होते हैं। ऑडिट रिकॉर्ड प्रत्येक निर्णय को इवेंट और पॉलिसी वर्ज़न से जोड़ते हैं, और एक रीप्ले जॉब अपरिवर्तनीय तथ्यों से प्रोजेक्शन का पुनर्निर्माण करता है।
सामान्य गलतियाँ
- प्रत्येक अनुरोध के लिए सिंक्रोनस रूप से बिलिंग तालिकाओं को पढ़ना → भुगतान लेटेंसी और आउटेज ऑथराइजेशन आउटेज बन जाते हैं → अपरिवर्तनीय तथ्यों को रीड-ऑप्टिमाइज़्ड स्नैपशॉट में प्रोजेक्ट करें।
- केवल फ़ीचर के आधार पर कैशिंग करना → एक टेनेंट या सब्जेक्ट को दूसरे स्कोप का निर्णय मिल सकता है → कुंजी में टेनेंट, सब्जेक्ट स्कोप और पॉलिसी वर्ज़न शामिल करें।
- आगमन क्रम में इवेंट्स लागू करना → एक पुराना रद्दीकरण या नवीनीकरण नए स्टेट को ओवरराइट कर सकता है → IDs को डिडुप्लिकेट करें और लागू वर्ज़न से पुराने वर्ज़न को अस्वीकार करें।
- हर जगह तत्काल रिवोकेशन का वादा करना → यह डिज़ाइन नेटवर्क और कैश लागतों को छुपाता है → एक मापने योग्य रिवोकेशन SLO बताएं और एक डिनाई फेंस लागू करें।
- सशुल्क या सुरक्षा फ़ीचर्स के लिए फेल ओपन होना → स्टेल एक्सेस एक राजस्व या सुरक्षा घटना बन जाता है → जोखिम के अनुसार फ़ीचर्स को वर्गीकृत करें और जहां आवश्यक हो वहां फेल क्लोज़ करें।
फॉलो-अप प्रश्न और उत्तर
आप टेनेंट के केवल 10 प्रतिशत उपयोगकर्ताओं के लिए किसी फ़ीचर का समर्थन कैसे करते हैं?
कमर्शियल एंटाइटेलमेंट और रोलआउट टारगेटिंग को अलग रखें। एंटाइटेलमेंट स्नैपशॉट बताता है कि टेनेंट के पास फ़ीचर है; एक स्थिर सब्जेक्ट टारगेटिंग की के साथ एक इवैल्यूएशन संदर्भ रोलआउट नियम लागू करता है। दोनों निर्णयों को रिकॉर्ड करें ताकि एक सपोर्ट इंजीनियर "खरीदा नहीं गया" और "रोलआउट द्वारा चयनित नहीं" के बीच अंतर कर सके।
जब रद्दीकरण इवेंट में देरी होती है तो क्या होता है?
प्रोजेक्शन आयु और इवेंट लैग को प्रदर्शित करें, रिवोकेशन SLO के उल्लंघन से पहले अलर्ट करें, और उपलब्ध होने पर बिलिंग वर्ज़न या डिनाई फेंस का उपयोग करें। अनुपस्थित हार्टबीट से रद्दीकरण का अनुमान न लगाएं। जैसे ही इवेंट आता है, इसे इडेम्पोटेंट रूप से लागू करें और सभी प्रभावित स्कोप्स को अमान्य करें।
आप शार्ड्स के बीच टेनेंट को कैसे माइग्रेट करते हैं?
टेनेंट मेटाडेटा में एक माइग्रेशन एपोक (epoch) लिखें, सीमित कटओवर के दौरान दोहरा रीड (dual-read) करें, और एक ऐसा फेंस प्रकाशित करें जो किसी पुराने शार्ड को अलाउ सर्व करने से रोकता है। पुरानी प्रतिलिपि को हटाने से पहले काउंट्स, वर्ज़न और सैंपल्ड निर्णयों को सत्यापित करें; रोलबैक के लिए रीप्ले करने योग्य तथ्यों को बनाए रखें।