सिस्टम डिज़ाइन इंटरव्यू: आप एक डिस्ट्रीब्यूटेड रेट लिमिटर कैसे डिज़ाइन करेंगे?

प्रांप्ट और संदर्भ

यह प्रश्न यह परीक्षण करता है कि क्या “N रिक्वेस्ट्स प्रति मिनट” एक संचालन योग्य कंट्रोल प्लेन और डेटा प्लेन बन सकता है या नहीं। एक लिमिटर निष्पक्षता और व्यावसायिक प्राथमिकता को बनाए रखते हुए क्षमता की सुरक्षा करता है; डिस्ट्रीब्यूटेड नोड्स और साझा स्थिति (shared state) अनुमान (समीपवर्ती मान) प्रस्तुत करते हैं। पॉलिसी, एल्गोरिदम, स्टोरेज, रिस्पॉन्स, फॉलबैक, रोलआउट और मेट्रिक्स को कवर करें।

साक्षात्कारकर्ता क्या परीक्षण करता है

मजबूत उत्तर टोकन बकेट, लीकी बकेट, फिक्स्ड विंडो और स्लाइडिंग विंडो की तुलना करने से पहले डाइमेंशन्स, विंडोज, बर्स्ट और विफलता सिमेंटिक्स को स्पष्ट करते हैं। वे रिक्वेस्ट निर्णयों से पॉलिसी वितरण को अलग करते हैं, एटॉमिक काउंटर्स, हॉट कीज, मल्टी-रीजन व्यवहार और Redis विफलता की व्याख्या करते हैं, और कार्रवाई योग्य Retry-After सिग्नल लौटाते हैं। वे शैडो रोलआउट, त्रुटि बजट (error budgets) और ऑडिट किए गए बाईपास पर भी चर्चा करते हैं।

स्पष्ट करने हेतु प्रश्न

क्या की (key) एक API, टेनेंट, उपयोगकर्ता, IP या इनका संयोजन है? क्या प्रीमियम ग्राहकों को प्राथमिकता दी जाती है?
क्या हम निरंतर दर (sustained rate), बर्स्ट आकार, समवर्तीता (concurrency) या कई संसाधनों को नियंत्रित करते हैं?
क्या अतिरिक्त रिक्वेस्ट विफल होती है, कतार में लगती है, डिग्रेड होती है या उसे थोड़ा ओवरएज प्राप्त होता है? क्या वैश्विक निरंतरता (global consistency) की आवश्यकता है?
क्या किसी अनुपलब्ध लिमिटर को फेल-ओपन होना चाहिए या फेल-क्लोज़्ड? कौन से रूट उच्च जोखिम वाले हैं?
पॉलिसियां कितनी बार बदलती हैं, और क्या हमें क्रमिक रोलआउट, ऑडिट, रोलबैक और तत्काल प्रभाव की आवश्यकता है?

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

“मैं पॉलिसी नियंत्रण को रिक्वेस्ट-टाइम निर्णयों से अलग करूँगा। टेनेंट, उपयोगकर्ता और रूट को एक की (key) में सामान्यीकृत (normalize) करें; डेटा प्लेन Redis Lua में एक एटॉमिक टोकन बकेट चलाता है और शेष कोटा तथा पुनः प्रयास का समय लौटाता है। वर्ज़न की गई पॉलिसियों को कैश किया जाता है, जबकि स्थानीय कैश तेज़ रिजेक्शन कर सकता है लेकिन साझा स्थिति अंतिम निर्णय लेती है। एक छोटे साझा-स्टोर आउटेज के दौरान, कम जोखिम वाले रूट टेनेंट आपातकालीन बजट का उपयोग करते हैं और फेल-ओपन होते हैं; उच्च जोखिम वाले रूट फेल-क्लोज़्ड होते हैं और पेज भेजते हैं। शैडो मोड, बर्न रेट, हॉट-की मेट्रिक्स और क्षेत्रीय त्रुटि सीमाएं रोलआउट का मार्गदर्शन करती हैं।”

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

चरण 1: क्षमता और निष्पक्षता को परिभाषित करें

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

चरण 2: एक एल्गोरिदम चुनें

टोकन बकेट नियंत्रित बर्स्ट की अनुमति देता है और APIs के लिए उपयुक्त है; लीकी बकेट आउटपुट को सुचारू (smooth) करता है; स्लाइडिंग विंडो सहज हैं लेकिन अधिक स्टेट की लागत लेती हैं। जब स्टेट Redis में साझा की जाती है, तो एटॉमिक स्क्रिप्ट के अंदर Redis TIME का उपयोग करें ताकि प्रत्येक नोड एक ही क्लॉक का उपयोग करे, बीता हुआ समय शून्य पर क्लैंप करें, और स्टेट क्लीनअप तथा एक सटीक सीमा परिभाषित करें।

चरण 3: कीज और पॉलिसी का मॉडल बनाएं

मेथड, रूट, टेनेंट, प्रिंसिपल और रीजन को सामान्यीकृत करें ताकि नोड्स समान की (key) प्राप्त करें। एक पॉलिसी में सीमा, बर्स्ट, स्कोप, प्राथमिकता, वर्ज़न, प्रभावी समय और स्वामी (owner) शामिल होते हैं। अज्ञात पॉलिसी एक सुरक्षित बेसलाइन पर वापस आ जाती है; क्लाइंट अपना स्वयं का कोटा प्रदान नहीं कर सकते हैं।

चरण 4: निर्णय को एटॉमिक बनाएं

एक साझा ऑपरेशन स्थिति को पढ़ता है, टोकन फिर से भरता है, लागत काटता है और TTL को अपडेट करता है। Redis Lua, एक एटॉमिक डेटाबेस ऑपरेशन, या एक साइडकार काम कर सकता है; महत्वपूर्ण बात यह है कि रीड-देन-राइट रेस कंडीशन से बचा जाए। शेष टोकन, रीसेट समय और पॉलिसी वर्ज़न लौटाएं।

चरण 5: हॉट कीज और रीजन्स को संभालें

एक लोकप्रिय टेनेंट किसी एक की (key) को हॉटस्पॉट में बदल सकता है। इसके बजट को शार्ड करें और एक समन्वयक (coordinator) में केवल तभी मर्ज करें यदि ओवरएज सीमा स्वीकार्य हो। मल्टी-रीजन सिस्टम क्षेत्रीय कोटा और अतुल्यकालिक (async) वैश्विक एकत्रीकरण का उपयोग कर सकते हैं; सख्त वैश्विक निरंतरता उपलब्धता और विलंबता (latency) की कीमत पर आती है।

चरण 6: विफलता और फॉलबैक डिज़ाइन करें

रूट के जोखिम के आधार पर फेल-ओपन या फेल-क्लोज़्ड चुनें और एक स्थानीय आपातकालीन बजट निर्धारित करें। जब पॉलिसी स्टोरेज अनुपलब्ध हो, तो कम TTL वाले अंतिम वर्ज़न का उपयोग करें। रिकवरी से सभी संचित मांग एक साथ जारी नहीं होनी चाहिए। प्रत्येक बाईपास और डिग्रेडेड निर्णय का ऑडिट करें।

चरण 7: परिवर्तनों को रोल आउट करें

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

चरण 8: परिणामों को मापें

अनुमति/अस्वीकृति दर, शेष कोटा, p95 निर्णय विलंबता, हॉट कीज, स्टोरेज त्रुटियां, पॉलिसी वर्ज़न्स, गलत-अस्वीकृति अपील और बैकएंड ओवरलोड की निगरानी करें। उन्हें 5xx, कतार गहराई (queue depth) और टेल लेटेंसी के साथ सहसंबंधित करें; बहुत कम लिमिटिंग सुरक्षा करने में विफल रहती है, बहुत अधिक व्यवसाय को नुकसान पहुँचाती है।

एटॉमिक टोकन-बकेट स्यूडोकोड

text

now = redis_time()
state = load(key) or {tokens: burst, at: now}
elapsed = max(0, now - state.at)
state.tokens = min(burst, state.tokens + elapsed * rate)
allowed = state.tokens >= cost
if allowed:
    state.tokens -= cost
state.at = now
save_atomically(key, state, ttl)
return allowed, state.tokens, retry_after(state)

ट्रेड-ऑफ और सीमाएं

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

रेट लिमिटिंग न तो कोई कतार है और न ही क्षमता योजना (capacity planning), सर्किट ब्रेकिंग या प्रमाणीकरण का विकल्प है। कतारें उन अनुरोधों के अनुकूल होती हैं जो प्रतीक्षा कर सकते हैं; एक लिमिटर ओवरलोड को विलंबता के रूप में छिपाने के बजाय संसाधन सीमा पर तुरंत अस्वीकार कर देता है।

रोलआउट योजना और साक्ष्य

एक उच्च-मात्रा वाले API के लिए पॉलिसी मॉडल और टोकन-बकेट डेटा प्लेन बनाएं, एक दिन के लिए शैडो मोड चलाएं, फिर कुछ टेनेंट्स को सक्षम करें। Microsoft Well-Architected थ्रॉटलिंग को सक्रिय ओवरलोड नियंत्रण के रूप में मानता है; DataInterview और System Design School सामग्री एल्गोरिदम चयन, साझा स्थिति और Retry-After पर जोर देती है।

पायलट से बाहर निकलने के मानदंड

ट्रैफ़िक स्पाइक्स, साझा-स्टोर विफलता, रोलबैक और एक हॉट टेनेंट के अभ्यासों के बाद, विलंबता लक्ष्य अभी भी बने हुए हैं; प्रत्येक गलत अस्वीकृति का एक कारण है; फॉलबैक बजट काम करते हैं; और पॉलिसियों के स्वामी, वर्ज़न और ऑडिट रिकॉर्ड हैं।

यह कैसे साबित करें कि लाभ वास्तविक है

टेनेंट, रूट और रीजन के आधार पर विभाजित करके पहले और बाद के बैकएंड ओवरलोड, 5xx, p99 विलंबता, अस्वीकृति दर, गलत-अस्वीकृति दर और स्टोरेज लागत की तुलना करें। क्षमता के लिए सामान्यीकृत करें ताकि प्राकृतिक कम-ट्रैफ़िक अवधि को सफलता समझने की भूल न हो।

सामान्य गलतियाँ और अनुवर्ती प्रश्न

प्रत्येक नोड पर स्थानीय काउंटर पर्याप्त हैं

प्रत्येक नोड अपना स्वयं का कोटा जारी करता है, इसलिए एक क्लाइंट नोड्स को बदलकर सीमा से अधिक हो सकता है। सन्निकटन का परिमाण निर्धारित करें या महत्वपूर्ण रूट्स के लिए साझा स्थिति/क्षेत्रीय बजट का उपयोग करें।

केवल एक फिक्स्ड विंडो का उपयोग करना

विंडो सीमाएं एक संक्षिप्त दोहरे बर्स्ट की अनुमति देती हैं। टोकन या स्लाइडिंग विंडो का उपयोग करें और स्थिति लागत तथा सटीकता की व्याख्या करें।

लिमिटर विफल होने पर प्रत्येक अनुरोध को जाने देना

उच्च जोखिम वाले रूट अपनी अंतिम सुरक्षा खो देते हैं। पेजिंग के साथ, जोखिम के आधार पर आपातकालीन बजट और फेल-ओपन/क्लोज़्ड चुनें।

आप प्रीमियम टेनेंट्स को नुकसान पहुँचाने से कैसे बचते हैं?

टेनेंट कोटा और प्राथमिकता कॉन्फ़िगर करें, साझा और गारंटीकृत पूल को अलग करें, और प्रत्येक छूट को समाप्ति और ऑडिट ट्रेल दें।

क्लाइंट्स को पुनः प्रयास कैसे करना चाहिए?

Retry-After का सम्मान करें, जिटर्ड बैकऑफ़ का उपयोग करें, और 429 का हमेशा पुनः प्रयास न करें। स्वचालित पुनः प्रयासों के लिए इडेम्पोटेंट अनुरोधों की आवश्यकता होती है।

आप एक नई पॉलिसी को कैनरी कैसे करते हैं?

शैडो मोड में गणना करें, टेनेंट या प्रतिशत के आधार पर सक्षम करें, अस्वीकृति, रूपांतरण (conversion) और बैकएंड लोड की तुलना करें, और रोलबैक के लिए पॉलिसी का वर्ज़न बनाएं।