सिस्टम डिज़ाइन इंटरव्यू: मल्टी-टेनेंट कोटा और यूसेज मीटरिंग सर्विस डिज़ाइन करना

1. प्रश्न और संदर्भ

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

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

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

3. उत्तर देने से पहले पूछे जाने वाले स्पष्टीकरण

1. क्या हम रिक्वेस्ट रेट, एक साथ चलने वाले जॉब्स, स्टोरेज क्षमता, या बिलिंग अवधि में संचयी (क्युमुलेटिव) उपयोग को सीमित कर रहे हैं?
2. क्या स्कोप ऑर्गनाइज़ेशन, टेनेंट, प्रोजेक्ट, यूज़र या रिसोर्स इंस्टेंस है, और क्या सीमाएं पदानुक्रम (हायरार्की) में नीचे इनहेरिट होती हैं?
3. सीमा समाप्त होने पर, क्या सिस्टम को अस्वीकार (रिजेक्ट), कतारबद्ध (कतारबद्ध/क्यू), डिग्रेड, या बिलिंग के लिए ओवरएज की अनुमति देनी चाहिए?
4. क्या स्ट्रांग मल्टी-रीजन कंसिस्टेंसी आवश्यक है, और रिकॉन्सिलिएशन से पहले कितना इवेंट विलंब स्वीकार्य है?

4. 30-सेकंड का उत्तर ढांचा

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

5. चरण-दर-चरण विस्तृत उत्तर

चरण 1: कोटा मॉडल और स्कोप परिभाषित करें

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

चरण 2: सिंक्रोनस जांच और एटॉमिक रिज़र्वेशन्स डिज़ाइन करें

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

checkAndReserve(tenant, dimensions, amount, requestId, configVersion)
  verify configVersion is active
  if requestId already committed: return previous decision
  atomically check remaining quota and add reservation
  persist reservation with expiry and requestId
  return reservationId and retryAfter

चरण 3: यूसेज इवेंट्स को मीटरिंग एग्रीगेशन से अलग करें

सफलता, विफलता, रद्दीकरण और समाप्ति पर इवेंट्स उत्सर्जित होने चाहिए। प्रत्येक इवेंट में टेनेंट, प्रोजेक्ट, रिसोर्स, मात्रा, यूनिट, इवेंट का समय और एक यूनिक इवेंट ID होती है। कम से कम एक बार डिलीवरी (at-least-once delivery) के साथ, कंज्यूमर्स इवेंट ID द्वारा डुप्लिकेट हटाते हैं; आउट-ऑफ़-ऑर्डर इवेंट्स इवेंट-टाइम विंडो या रीप्ले करने योग्य लेज़र का उपयोग करते हैं। एग्रीगेट्स क्वेरीज़, थ्रेशोल्ड अलर्ट्स और बिलिंग इनपुट की सेवा करते हैं, लेकिन उन्हें सिंक्रोनस रिज़र्वेशन लेज़र को ओवरराइट नहीं करना चाहिए।

चरण 4: ओवरएज, कोटा परिवर्तन और निष्पक्षता संभालें

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

चरण 5: मल्टी-रीजन व्यवहार, रिकवरी और रिकॉन्सिलिएशन

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

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

मैं कोटा कैटलॉग, सिंक्रोनस एडमिशन इंजन, रिज़र्वेशन लेज़र, एसिंक्रोनस मीटरिंग पाइपलाइन और ऑडिट क्वेरीज़ को अलग करूँगा। कैटलॉग ऑर्गनाइज़ेशन, टेनेंट और प्रोजेक्ट स्कोप के साथ-साथ रेट, कंकरेंट और एलोकेशन लिमिट्स को परिभाषित करता है। एडमिशन एटॉमिक चेक-एंड-रिज़र्व के लिए टेनेंट डाइमेंशन्स और एक इडेम्पोटेंसी ID का उपयोग करता है; लंबे जॉब्स को एक रिज़र्वेशन ID मिलती है जो पूर्णता, रद्दीकरण और समाप्ति को इडेम्पोटेंट बनाती है। सफलता और विफलता के इवेंट्स एक at-least-once पाइपलाइन में प्रवेश करते हैं; कंज्यूमर्स इवेंट ID द्वारा डिडुप्लिकेट करते हैं और एडमिशन लेज़र को ओवरराइट किए बिना अलर्ट और बिलिंग के लिए इवेंट समय के अनुसार एग्रीगेट करते हैं। प्रति रिसोर्स, मल्टी-रीजन व्यवहार या तो ऑथॉरिटेटिव होता है या बाउंडेड-ओवरसेल। विफलता के दौरान, हार्ड कोटा को सुरक्षित रखें; रिकवरी के बाद, रीप्ले और रिकॉन्सिलिएशन करें, जिसमें प्रत्येक परिवर्तन और क्षतिपूर्ति ऑडिट योग्य हो।

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

• एक शेयर्ड काउंटर का उपयोग करना → एक हॉट टेनेंट सभी को धीमा कर देता है → टेनेंट द्वारा शार्ड करें और निष्पक्ष कैप्स लागू करें।
• एसिंक्रोनस एग्रीगेट को एडमिशन तय करने देना → इवेंट लैग के कारण ओवरसेल होता है → एडमिशन की सत्यता के रूप में एक एटॉमिक रिज़र्वेशन लेज़र रखें।
• केवल रेट लिमिट्स पर चर्चा करना → लंबे जॉब्स और स्टोरेज असीमित क्षमता की खपत करते हैं → रेट, कंकरेंट और एलोकेशन लिमिट्स को मॉडल करें।
• केवल रिक्वेस्ट IDs को डिडुप्लिकेट करना → पुनः प्रयास किए गए इवेंट्स को दो बार गिना जाता है → रिज़र्वेशन्स और यूसेज इवेंट्स के लिए अलग-अलग इडेम्पोटेंसी कीज़ का उपयोग करें।
• कोटा कम करते समय बैलेंस को ओवरराइट करना → स्वीकृत कार्य अचानक अस्वीकार हो जाता है → कॉन्फ़िगरेशन को वर्शन करें और मौजूदा रिज़र्वेशन्स का निरीक्षण करें।

8. फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: केवल Redis काउंटर पर ही निर्भर क्यों न रहें?

कम विलंबता (लो-लेटेंसी) वाले विंडो आंकड़ों के लिए एक काउंटर उपयोगी है, लेकिन क्रॉस-रिसोर्स एटॉमिक रिज़र्वेशन्स, जॉब समाप्ति, कॉन्फ़िगरेशन वर्शन्स और ऑडिट के लिए एक अधिक संपूर्ण लेज़र की आवश्यकता होती है। काउंटर केवल तभी एक तेज़ पाथ हो सकता है जब एक ऑथॉरिटेटिव रिकॉर्ड और पुनर्निर्माण प्रक्रिया मौजूद हो।

फॉलो-अप 2: आप डुप्लिकेट यूसेज इवेंट्स को दो बार बिल होने से कैसे रोकते हैं?

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

फॉलो-अप 3: क्या आप मल्टी-रीजन पार्टीशन के दौरान कार्य को स्वीकार करना जारी रखते हैं?

उन हार्ड कोटा के लिए काम को रोकें या रिसोर्सेज को ऑथोरिटी पर रूट करें जो ओवरसेल नहीं कर सकते। बाउंडेड ओवरसेल बजट वाले सॉफ्ट कोटा के लिए, क्षेत्रीय आवंटन से काम स्वीकार करें और अधिकतम जोखिम रिकॉर्ड करें। यह निर्णय व्यावसायिक नुकसान और कंसिस्टेंसी के उद्देश्यों पर निर्भर करता है।

फॉलो-अप 4: आप कोटा सर्विस का परीक्षण कैसे करते हैं?

एक हॉट टेनेंट, कंकरेंट रिज़र्वेशन्स, डुप्लिकेट और आउट-ऑफ़-ऑर्डर इवेंट्स, कॉन्फ़िगरेशन डाउनग्रेड, रीजनल पार्टीशन, कंज्यूमर रीप्ले और अवधि रोलओवर का लोड-टेस्ट करें। पुष्टि करें कि हार्ड लिमिट्स कभी न टूटें, इडेम्पोटेंट ऑपरेशन्स स्थिर रहें, और लेज़र, एग्रीगेट्स तथा बिलिंग रिकवरी के बाद पूरी तरह सुसंगत (कन्वर्ज) हो जाएं।