प्रॉम्प्ट और संदर्भ
प्लेटफ़ॉर्म में कई क्षेत्रों (regions) में सैकड़ों गेटवे इंस्टेंस हैं। उत्पाद टीमों को टेनेंट, एप्लिकेशन, एंडपॉइंट और प्लान के आधार पर अनुरोध-प्रति-सेकंड (RPS), समवर्तीता (concurrency) और दैनिक कोटा की आवश्यकता होती है, जिसके परिवर्तन कुछ ही मिनटों में प्रभावी होने चाहिए। एक टेनेंट को साझा क्षमता का उपभोग नहीं करना चाहिए, फिर भी कोटा सेवा में संक्षिप्त आउटेज के दौरान कोर API उपलब्ध रहने चाहिए।
इंटरव्यू कंट्रोल-प्लेन/डेटा-प्लेन सेपरेशन, काउंटिंग मॉडल, वितरण कंसिस्टेंसी, क्रॉस-रीजन ट्रेड-ऑफ़ और विफलता व्यवहार का परीक्षण करता है। Envoy स्थानीय और ग्लोबल रेट लिमिटिंग में अंतर करता है, जबकि RFC 9331 HTTP RateLimit फ़ील्ड को परिभाषित करता है; प्रोटोकॉल, उत्पाद नीति और रनटाइम निर्णय को आपस में जोड़ें।
इंटरव्यूअर क्या मूल्यांकन करता है
पॉलिसी संरचना, वर्ज़न और अनुमोदन, डिस्क्रिप्टर कीज़, टोकन बकेट या स्लाइडिंग विंडो, हॉट टेनेंट्स, क्रॉस-रीजन काउंटिंग, कॉन्फ़िगरेशन वितरण, कैशिंग, फ़ेल-ओपन बनाम फ़ेल-क्लोज़्ड, कोटा हेडर, ऑडिट और लागत को कवर करें।
स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न
- क्या कोटा हार्ड लिमिट हैं, सॉफ्ट अलर्ट हैं या दोनों हैं, और क्या ट्रैफ़िक बर्स्ट कर सकता है या भविष्य की क्षमता उधार ले सकता है?
- किन आयामों (dimensions) को ग्लोबल सटीकता की आवश्यकता है और कौन से आयाम सीमित क्षेत्रीय अनुमान (bounded regional approximation) की अनुमति देते हैं?
- प्रोपेगेशन और रोलबैक लक्ष्य क्या हैं, और किसी पॉलिसी के बासी (stale) होने से पहले एक गेटवे कितने समय तक डिस्कनेक्ट रह सकता है?
- क्या सीमा से अधिक (over-limit) रिस्पॉन्स में पुनः प्रयास का समय (retry timing), शेष कोटा और बिलिंग इवेंट प्रदर्शित होने चाहिए?
- लिमिटर आउटेज के दौरान किन कोर एंडपॉइंट्स को चालू रहना चाहिए?
30-सेकंड का उत्तर
"कंट्रोल प्लेन स्वीकृत, वर्ज़न किए गए नियमों को संग्रहीत करता है, उन्हें गेटवे डिस्क्रिप्टर्स में संकलित करता है, और डेल्टा वितरित करता है। डेटा प्लेन स्थानीय स्तर पर तेज़ निर्णय लेता है; केवल वैश्विक सटीकता की आवश्यकता वाले आयाम ही साझा लिमिटर को कॉल करते हैं। टोकन बकेट बर्स्ट को संभालते हैं और काउंटर टेनेंट और एंडपॉइंट द्वारा अलग किए जाते हैं। नीतियों में TTL, चेकसम और रोलबैक वर्ज़न होते हैं। एंडपॉइंट जोखिम के आधार पर फ़ेल-ओपन या फ़ेल-क्लोज़्ड चुनें, मानक RateLimit जानकारी लौटाएं, और निर्णय के कारण का ऑडिट करें।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: पॉलिसी और रिलीज़ वर्कफ़्लो को परिभाषित करें
एक पॉलिसी में टेनेंट, एप्लिकेशन, एंडपॉइंट, विंडो, रेट, क्षमता, समवर्तीता (concurrency), दैनिक कोटा, रीजन स्कोप और प्राथमिकता शामिल होती है। गेटवे को मनमाने उत्पाद फ़ील्ड की व्याख्या नहीं करनी चाहिए; कंट्रोल प्लेन उन्हें स्थिर डिस्क्रिप्टर्स में संकलित करता है।
policy v42:
subject: tenant:acme / app:billing
route: POST /invoices
rate: 200 requests/second
burst: 400
scope: globalरिलीज़ के लिए अनुमोदन, स्थिर टकराव जांच (static conflict checks), ट्रैफ़िक सिमुलेशन और एक हस्ताक्षरित वर्ज़न की आवश्यकता होती है। लेखक, कारण, अपेक्षित प्रभाव और रोलबैक पॉइंटर रखें; ऑडिट किए गए वर्ज़न को कभी भी अधिलेखित (overwrite) न करें।
चरण 2: काउंटिंग और शार्डिंग चुनें
कम समय के बर्स्ट के लिए गेटवे पर स्थानीय टोकन बकेट का उपयोग करें। एक साझा लिमिटर डिस्क्रिप्टर द्वारा ग्लोबल आयामों की गणना कर सकता है। दैनिक कोटा के लिए, स्पष्ट विंडो सीमाओं और एक क्लॉक सोर्स के साथ एटॉमिक विंडो काउंटर या शार्ड किए गए कोटा का उपयोग करें।
टेनेंट, एप्लिकेशन और एंडपॉइंट के आधार पर शार्ड करें ताकि एक हॉट की बाधा (bottleneck) न बने। एक हॉट टेनेंट को श्रेणीबद्ध टोकन, पूर्व-आवंटित क्षमता, या एक समर्पित शार्ड प्राप्त हो सकता है, जिसमें अल्पकालिक ओवरएज और अंतिम बिलिंग का स्पष्ट उपचार हो।
चरण 3: कंसिस्टेंसी के साथ पॉलिसी वितरित करें
गेटवे पर वर्ज़न और चेकसम के साथ संकलित नीतियों को स्ट्रीम करें। केवल मोनोटोनिक रूप से बढ़ते हुए, वैध रूप से हस्ताक्षरित वर्ज़न स्वीकार करें; स्टार्टअप पर अंतिम वैध स्नैपशॉट लोड करें। छूटे हुए अपडेट अपने TTL के बाद गेटवे को बासी (stale) चिह्नित करते हैं और एक अलर्ट जारी करते हैं।
क्षेत्र के भीतर स्थानीय वितरण को प्राथमिकता दें। क्रॉस-रीजन पॉलिसी एक ग्लोबल वर्ज़न और स्पष्ट प्रभावी समय का उपयोग करती है। रोलबैक एक अन्य वर्ज़न है, न कि इतिहास को फिर से लिखना; गेटवे पावती (acknowledgement) के बाद वर्ज़न कवरेज की रिपोर्ट करते हैं।
चरण 4: कंसिस्टेंसी, बर्स्ट और निष्पक्षता को संभालें
ग्लोबल सटीक गणना नेटवर्क लेटेंसी और साझा-स्थिति (shared-state) लागत को बढ़ाती है। उच्च-जोखिम या संविदात्मक (contractual) आयामों के लिए मजबूत समन्वय आरक्षित करें और अन्यत्र सीमित त्रुटि की अनुमति दें। बैकएंड समवर्तीता के साथ बर्स्ट क्षमता को संरेखित करें; केवल गेटवे बकेट बढ़ाने से भी सेवा ओवरलोड हो सकती है।
टेनेंट निष्पक्षता को साझा कनेक्शन पूल की रक्षा करनी चाहिए। कोटा निर्णयों को कॉनकरेंसी बल्कहेड्स, कतार की लंबाई और प्राथमिकता के साथ जोड़ें। रिकॉर्ड करें कि ट्रैफ़िक अस्वीकार किया गया था या कतारबद्ध किया गया था और क्यों, ताकि ग्राहक केवल एक संख्या से अधिक का निदान कर सकें।
चरण 5: विफलता और डिग्रेडेशन को परिभाषित करें
यदि लिमिटर अगम्य है, तो कम जोखिम वाले केवल-पढ़ने योग्य (read-only) एंडपॉइंट सीमित फ़ेल-ओपन के साथ नवीनतम स्थानीय स्नैपशॉट का उपयोग कर सकते हैं; राइट्स, बिलिंग और महंगे एंडपॉइंट फ़ेल-क्लोज़्ड या सख्त स्थानीय कैप का उपयोग करते हैं। प्रत्येक डिग्रेडेड निर्णय को एक समाप्ति (expiry) दें और पुनर्प्राप्ति के बाद अनुमानित गणनाओं का मिलान करें या उन्हें चिह्नित करें।
गेटवे रीस्टार्ट, क्लॉक ड्रिफ्ट, डुप्लिकेट संदेशों और वितरण रुकावट का परीक्षण करें। एक दूषित स्नैपशॉट को अस्वीकार करें और अंतिम वैध वर्ज़न बनाए रखें; एक खाली कॉन्फ़िगरेशन का अर्थ कभी भी असीमित कोटा नहीं होना चाहिए।
चरण 6: प्रोटोकॉल, ऑडिट और ऑब्जर्वेबिलिटी
सीमा से अधिक रिस्पॉन्स पर स्थिर 429 सिमेंटिक्स लौटाएं और RFC 9331 के अनुसार व्याख्या योग्य सीमा, शेष और रीसेट जानकारी प्रदर्शित करें। जिन टेनेंट्स को सटीक संख्याएं नहीं देखनी चाहिए, उनके लिए एक टियर संदेश का उपयोग करें। आंतरिक रूप से पॉलिसी वर्ज़न, डिस्क्रिप्टर, क्षेत्र, काउंटर सोर्स, डिग्रेडेड स्थिति और अनुरोध ट्रेस रिकॉर्ड करें।
वर्ज़न कवरेज, निर्णय लेटेंसी, अस्वीकृति दर, हॉट कीज़, गणना त्रुटि, डिग्रेडेशन अवधि और रोलबैक की निगरानी करें। शैडो मोड में नई नीतियों का मूल्यांकन करें और रिलीज़ से पहले अस्वीकृति परिवर्तनों की तुलना करें।
एक मजबूत नमूना उत्तर
मैं स्वीकृत नीतियों को वर्ज़न किए गए डिस्क्रिप्टर्स में संकलित करूँगा और कंट्रोल प्लेन से डेल्टा वितरित करूँगा। गेटवे कम लेटेंसी के लिए स्थानीय टोकन बकेट का उपयोग करते हैं, केवल उन आयामों के लिए साझा सेवा को कॉल करते हैं जिन्हें वैश्विक सटीकता की आवश्यकता होती है। नीतियों में हस्ताक्षर, TTL, चेकसम और रोलबैक वर्ज़न होते हैं, जो टेनेंट, एप्लिकेशन, एंडपॉइंट और क्षेत्र द्वारा अलग किए जाते हैं। एंडपॉइंट जोखिम के आधार पर डिग्रेड करें, स्थिर 429 और RateLimit जानकारी लौटाएं, और वर्ज़न, काउंटर सोर्स और सन्निकटन स्थिति रिकॉर्ड करें।
सामान्य गलतियाँ
- प्रत्येक अनुरोध को एक केंद्रीय काउंटर पर भेजना → लेटेंसी और विफलता डोमेन बढ़ते हैं → स्थानीय निर्णय लें और जोखिम के अनुसार विश्व स्तर पर समन्वय करें।
- कॉन्फ़िगरेशन को अधिलेखित करना → कोई ऑडिट या रोलबैक नहीं → अनुमोदन, हस्ताक्षर और मोनोटोनिक वर्ज़न का उपयोग करें।
- बर्स्ट या समवर्तीता के बिना दर निर्धारित करना → बैकएंड अभी भी फ्लड हो सकता है → टोकन, बल्कहेड्स और कतारों को जोड़ें।
- हमेशा फ़ेल-ओपन होना → राइट्स और बिलिंग अनियंत्रित हो जाते हैं → एंडपॉइंट जोखिम के आधार पर डिग्रेड करें।
- एक अस्पष्ट त्रुटि लौटाना → ग्राहक ट्रैफ़िक को समायोजित नहीं कर सकते → स्थिर स्थिति, रीसेट समय और एक ऑडिट योग्य कारण प्रदान करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: हर जगह मजबूत कंसिस्टेंसी की आवश्यकता क्यों नहीं है?
मजबूत कंसिस्टेंसी के लिए साझा स्थिति और नेटवर्क राउंड ट्रिप की आवश्यकता होती है, जिससे उपलब्धता कम होती है और लागत बढ़ती है। इसे संविदात्मक या सुरक्षा-महत्वपूर्ण आयामों के लिए आरक्षित करें और अन्यत्र सीमित-त्रुटि मॉडल प्रकाशित करें।
फॉलो-अप 2: आप क्रॉस-रीजन बर्स्ट को कैसे संभालते हैं?
ग्लोबल कैप के तहत क्षेत्रीय टोकन पूर्व-आवंटित करें। उच्च-मूल्य वाला ट्रैफ़िक संक्षेप में उधार ले सकता है, लेकिन उधार ली गई क्षमता और पुनर्भुगतान या बिलिंग नियमों को रिकॉर्ड करें ताकि एक क्षेत्र हावी न हो सके।
फॉलो-अप 3: प्रोपेगेशन विलंब का स्वामी कौन है?
गेटवे अपना अंतिम वैध वर्ज़न रखता है और खुद को बासी (stale) चिह्नित करता है जबकि कंट्रोल प्लेन कवरेज को ट्रैक करता है। TTL के बाद, एंडपॉइंट जोखिम के आधार पर कड़ा करें या रोकें; चुपचाप कभी भी असीमित न बनें।
फॉलो-अप 4: आप कैसे साबित करते हैं कि एक नई पॉलिसी ग्राहकों को नुकसान नहीं पहुँचाती है?
शैडो मूल्यांकन और ऐतिहासिक रीप्ले चलाएं, अस्वीकृति, लेटेंसी और टेनेंट वितरण की तुलना करें, स्वचालित गेट सेट करें, फिर वन-क्लिक रोलबैक वर्ज़न के साथ संकीर्ण रूप से कैनरी करें।