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

समस्या और उपयोग के मामले (Use Cases)

300 बैकएंड सेवाओं के लिए सार्वजनिक प्रवेश बिंदु (public entry point) डिज़ाइन करें। यह तीन सक्रिय क्षेत्रों (active regions) में पीक पर 500,000 अनुरोध प्रति सेकंड संभालता है और लगभग 20,000 रूट परिभाषाएं रखता है। गेटवे TLS को समाप्त (terminate) करता है, कॉल करने वालों को प्रमाणित करता है, कोर्स-ग्रेन्ड ऑथराइजेशन और कोटा लागू करता है, अनुरोधों को सामान्य (normalize) करता है, अपस्ट्रीम का चयन करता है, भारित कैनरी (weighted canaries) का समर्थन करता है, और मेट्रिक्स व ट्रेसेस उत्सर्जित करता है। 99.99% उपलब्धता लक्ष्य और 10 मिलीसेकंड से कम गेटवे-अतिरिक्त p99 लेटेंसी मान लें। ये इंटरव्यू के इनपुट्स हैं, किसी उत्पाद के बारे में दावे नहीं।

रूट और नीतिगत परिवर्तनों को 30 सेकंड के भीतर स्वस्थ गेटवे तक पहुंचना चाहिए। आपातकालीन क्रेडेंशियल निरस्तीकरण (revocations) के लिए एक तेज़ पथ की आवश्यकता होती है। एक ख़राब कॉन्फ़िगरेशन को सभी क्षेत्रों को डाउन नहीं करना चाहिए, और एक अनुपलब्ध कंट्रोल प्लेन को गेटवे को अंतिम ज्ञात अच्छे कॉन्फ़िगरेशन (last known good configuration) के साथ सेवा देने से नहीं रोकना चाहिए। बैकएंड बिजनेस लॉजिक, प्रतिक्रिया संयोजन (response composition), लंबे समय तक चलने वाले वर्कफ़्लो ऑर्केस्ट्रेशन और एप्लिकेशन-विशिष्ट प्राधिकरण गेटवे के बाहर रहते हैं।

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

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

एक मजबूत उत्तर सबसे पहले डेटा प्लेन को कंट्रोल प्लेन से अलग करता है। क्षेत्रीय गेटवे प्रक्रियाएं एक अपरिवर्तनीय स्थानीय स्नैपशॉट (immutable local snapshot) से अनुरोधों को पूरा करती हैं। कंट्रोल प्लेन रूट और नीति परिवर्तनों को मान्य, संस्करणित, संग्रहीत और वितरित करता है। यदि कोई उम्मीदवार प्रत्येक अनुरोध पर डेटाबेस या रिमोट कॉन्फ़िगरेशन लुकअप लगाता है, तो न तो लेटेंसी लक्ष्य पूरा होता है और न ही कंट्रोल-प्लेन विफलता अलगाव (failure isolation)।

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

क्षमता की पुनर्गणना की जा सकने योग्य होनी चाहिए। 500,000 अनुरोध प्रति सेकंड पर, एक औसत 2 KiB इनबाउंड अनुरोध प्रोटोकॉल ओवरहेड से पहले लगभग 500,000 × 2 KiB ≈ 0.95 GiB/s होता है। यदि एक बेंचमार्क किया गया गेटवे इंस्टेंस आवश्यक p99 पर सुरक्षित रूप से Q अनुरोध प्रति सेकंड बनाए रखता है, तो फ्लीट को कम से कम ceil(500,000 / Q) इंस्टेंस की आवश्यकता होती है, और फिर एक क्षेत्र के नुकसान के लिए अतिरिक्त क्षमता की। तीन समान क्षेत्रों में से एक को खोने से प्रत्येक शेष क्षेत्र का भार लगभग 167,000 से बढ़कर 250,000 अनुरोध प्रति सेकंड हो जाता है, जो 50% की वृद्धि है। क्षमता योजना में उस स्थिति को शामिल किया जाना चाहिए।

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

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्लाइंट कौन हैं? मान लें कि सार्वजनिक वेब, मोबाइल और पार्टनर क्लाइंट HTTP API का उपयोग कर रहे हैं। आंतरिक सेवा-से-सेवा ट्रैफ़िक एक अलग इनग्रेस या सर्विस मेश नीति का उपयोग कर सकता है।
• उपलब्धता इकाई (availability unit) क्या है? एक क्षेत्र में कम से कम तीन विफलता क्षेत्रों (failure zones) में फैले गेटवे इंस्टेंस शामिल हैं। तीनों क्षेत्र सक्रिय-सक्रिय (active-active) हैं, और वैश्विक रूटिंग एक अस्वस्थ क्षेत्र को हटा देती है।
• क्या रूट्स होस्टनेम, पाथ और मेथड द्वारा स्वतंत्र हैं? हाँ। मिलान क्रम नियतात्मक (deterministic) होना चाहिए, और अस्पष्ट रूट परिभाषाओं को प्रकाशन से पहले अस्वीकार कर दिया जाता है।
• कौन सी नीतियां समकालिक रूप से (synchronously) चलती हैं? हस्ताक्षर सत्यापन, रूट मिलान, एक कोर्स ऑथराइजेशन जांच, कोटा, अनुरोध सीमाएं और हेडर परिवर्तन। निर्णय लेने के लिए गेटवे द्वारा व्यावसायिक डेटा कभी भी फ़ेच नहीं किया जाता है।
• कॉन्फ़िगरेशन कितना ताज़ा होना चाहिए? सामान्य परिवर्तन 30 सेकंड के भीतर संयोजित (converge) हो जाते हैं। गेटवे अपने लागू संस्करण की रिपोर्ट करते हैं। सुरक्षा निरस्तीकरण पूर्ण स्नैपशॉट पुनर्निर्माण को बाध्य करने के बजाय कम टोकन जीवनकाल या एक छोटी अलग से वितरित डिनाई सूची (deny list) का उपयोग करते हैं।
• विभिन्न क्षेत्रों में कोटा कितने सटीक हैं? डिफ़ॉल्ट डिज़ाइन एक वैश्विक बजट से आवंटित क्षेत्रीय कोटा का उपयोग करता है। वास्तव में सख्त वैश्विक काउंटर प्रत्येक अनुरोध में एक क्रॉस-रीजन निर्भरता जोड़ देगा और इसे अलग से उचित ठहराया जाना चाहिए।
• क्या गेटवे पुनः प्रयास (retry) कर सकता है? केवल आइडम्पोटेंट (idempotent) अनुरोधों को, एक छोटे पुनः प्रयास बजट के साथ, यह साबित करने के बाद कि पहला प्रयास स्वीकार नहीं किया गया था। गैर-आइडम्पोटेंट राइट्स के लिए एप्लिकेशन आइडम्पोटेंसी कुंजी की आवश्यकता होती है या कोई स्वचालित पुनः प्रयास नहीं होता है।
• क्या बाहर रखा गया है? गेटवे से पहले DDoS स्क्रबिंग, सेवा कार्यान्वयन, डेटाबेस प्रतिकृति और एप्लिकेशन-स्तरीय लेनदेन अलग-अलग सिस्टम हैं।

30-सेकंड उत्तर रूपरेखा (30-Second Answer Framework)

"मैं स्वास्थ्य-सचेत (health-aware) वैश्विक रूटिंग के पीछे तीन सक्रिय क्षेत्रों में से प्रत्येक में एक स्टेटलेस गेटवे फ्लीट रखूँगा। प्रत्येक अनुरोध एक क्षेत्र में रहता है: गेटवे TLS को समाप्त करता है, स्थानीय कुंजी कैश से पहचान सत्यापित करता है, एक अपरिवर्तनीय रूट स्नैपशॉट से मिलान करता है, कोर्स नीति और एक क्षेत्रीय कोटा लागू करता है, फिर उसी क्षेत्र के एक स्वस्थ अपस्ट्रीम का चयन करता है। एक अलग कंट्रोल प्लेन प्रत्येक कॉन्फ़िगरेशन को मान्य करता है, एक संस्करण निर्दिष्ट करता है, इसे एक छोटे गेटवे कोहोर्ट में कैनरी करता है, और इसे एटॉमिक रूप से सक्रिय करता है; यदि वह प्लेन विफल हो जाता है तो गेटवे अंतिम ज्ञात अच्छे स्नैपशॉट के साथ सेवा जारी रखते हैं। मैं तीन समान क्षेत्रों में से एक के विफल होने के बाद 50% लोड वृद्धि के लिए प्रत्येक क्षेत्र का आकार निर्धारित करूँगा, ओवरलोड प्रवर्धन से बचने के लिए पुनः प्रयासों और कतारों को सीमित करूँगा, और अतिरिक्त लेटेंसी, रूट परिणामों, अपस्ट्रीम स्वास्थ्य, कॉन्फ़िगरेशन संस्करणों और क्षेत्रीय फेलओवर की निगरानी करूँगा।"

चरण-दर-चरण गहन विश्लेषण (Step-by-Step Deep Dive)

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

सामान्य अनुरोध प्रवाह है:

1. ग्लोबल DNS या एनीकास्ट एक स्वस्थ क्षेत्र का चयन करता है। क्षेत्रीय लोड बैलेंसर एक गेटवे इंस्टेंस का चयन करता है।
2. गेटवे TLS को समाप्त करता है, अनुरोध-आकार और कनेक्शन सीमाओं को लागू करता है, और एक अनुरोध ID जोड़ता है।
3. यह कैश्ड जारीकर्ता मेटाडेटा और सार्वजनिक कुंजियों का उपयोग करके एक हस्ताक्षरित टोकन की पुष्टि करता है। यह प्रत्येक अनुरोध के लिए पहचान प्रदाता (identity provider) को कभी कॉल नहीं करता है।
4. एक संकलित मैचर सक्रिय स्नैपशॉट से एक रूट का चयन करने के लिए होस्ट, मेथड और सामान्यीकृत पाथ का उपयोग करता है।
5. नीति श्रृंखला (policy chain) कोर्स स्कोप, क्षेत्रीय कोटा, हेडर, टाइमआउट और वैकल्पिक कैनरी चयन लागू करती है।
6. गेटवे स्थानीय रूप से कैश्ड सर्विस डिस्कवरी से एक स्वस्थ एंडपॉइंट चुनता है और एक सीमित समय सीमा (bounded deadline) के साथ अनुरोध अग्रेषित करता है।
7. यह परिणाम, लेटेंसी, रूट ID, अपस्ट्रीम क्लस्टर, कॉन्फ़िगरेशन संस्करण और ट्रेस संदर्भ को रिकॉर्ड करता है, फिर हॉट पाथ से टेलीमेट्री को स्ट्रीम करता है।

रूट परिभाषा डिक्लेरेटिव रह सकती है:

Route {
  id: string
  host: string
  methods: string[]
  path_template: string
  upstream_cluster: string
  auth_policy_id: string
  quota_policy_id: string
  timeout_ms: uint32
  retry_policy: { max_attempts, retryable_statuses }
  traffic_split: [{ revision, weight }]
}

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

सबसे बड़ा अड़चन (bottleneck) फ्लीट पैमाने पर कॉन्फ़िगरेशन सुरक्षा है। व्यक्तिगत परिवर्तनशील अपडेट भेजने से रूट, नीति और प्रमाणपत्र संस्करण असंगत हो सकते हैं। एक संस्करणित स्नैपशॉट सक्रियण इकाई को स्पष्ट बनाता है। गेटवे स्थानीय डिस्क या टिकाऊ नोड स्टोरेज पर नवीनतम सत्यापित स्नैपशॉट को बनाए रखते हैं, कम से कम एक पिछला संस्करण बनाए रखते हैं, और desired_version, downloaded_version, और active_version प्रदर्शित करते हैं। एक कंट्रोल-प्लेन आउटेज परिवर्तनों को रोकता है लेकिन ट्रैफ़िक को नहीं। एक दूषित या अधूरा स्नैपशॉट अस्वीकार कर दिया जाता है। एक आपातकालीन निरस्तीकरण को सभी 20,000 रूट्स के पुनर्संकलन की प्रतीक्षा नहीं करनी चाहिए: अल्पकालिक क्रेडेंशियल एक्सपोज़र को सीमित करते हैं, जबकि एक छोटी हस्ताक्षरित डिनाई सूची का अपना तेज़ वितरण चैनल और समाप्ति होती है।

क्षमता के लिए, खाली रिवर्स प्रॉक्सी के बजाय पूरी नीति श्रृंखला को बेंचमार्क करें। यदि एक परीक्षण किया गया इंस्टेंस लक्ष्य p99 पर 8,000 अनुरोध प्रति सेकंड बनाए रखता है, तो पीक ट्रैफ़िक को हेडरूम से पहले ceil(500,000 / 8,000) = 63 इंस्टेंस की आवश्यकता होती है। तीन समान क्षेत्रों के साथ, एक क्षेत्र की विफलता प्रत्येक उत्तरजीवी के लिए 250,000 अनुरोध प्रति सेकंड, या उस बेंचमार्क पर 32 इंस्टेंस छोड़ती है; प्रति क्षेत्र 40–45 की तैनाती परिचालन हेडरूम देती है। यह संख्या उदाहरणात्मक है और इसे वास्तविक TLS, टोकन सत्यापन, पेलोड आकार, लॉगिंग और अपस्ट्रीम लेटेंसी का उपयोग करके मापों द्वारा प्रतिस्थापित किया जाना चाहिए।

गेटवे को लोड संचित करने के बजाय शेड (shed) करना चाहिए। समवर्ती अनुरोधों, कनेक्शनों, अनुरोध निकायों, प्रति-रूट कतारों और टेलीमेट्री बफ़र्स पर सीमाएं लगाएं। अपस्ट्रीम में समय सीमा का प्रचार करें। सर्किट ब्रेकिंग एक विफल सेवा को प्रत्येक गेटवे कनेक्शन का उपभोग करने से रोकता है। केवल आइडम्पोटेंट विफलताओं के एक संकीर्ण सेट का पुनः प्रयास करें, जिटर का उपयोग करें, और प्रत्येक प्रयास को एक पुनः प्रयास बजट से चार्ज करें। जब कोई अपस्ट्रीम संतृप्त होता है, तो 503 को तुरंत वापस करना एक अनबाउंड कतार बनाने की तुलना में अधिक सुरक्षित है जो साझा गेटवे को समाप्त कर देती है।

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

हॉट पाथ पर कोटा क्षेत्रीय होते हैं। एक वैश्विक आवंटक किरायेदार (tenant) के बजट को क्षेत्रों के लिए छोटे पट्टों (leases) में विभाजित करता है, और क्षेत्रीय डेटा स्टोर एटॉमिक निर्णय लेते हैं। यह एक विभाजन को असीमित वैश्विक कोटा को गुणा करने से रोकता है, लेकिन एक अलग-थलग क्षेत्र केवल अपने पट्टे का उपभोग कर सकता है। यदि स्वतंत्र क्षेत्र प्रवेश देना जारी रखते हैं और बाद में सामंजस्य स्थापित करते हैं, तो उपलब्धता में सुधार होता है जबकि ओवर-एडमिशन संभव हो जाता है। उत्पाद स्वामी को उस सीमा का चयन करना होगा। विस्तृत टोकन-बकेट कार्यान्वयन प्रत्येक गेटवे के अंदर पुनर्निर्माण के बजाय दर-सीमक उपप्रणाली को सौंप दिया गया है।

AWS मल्टी-रीजन गेटवे के लिए सक्रिय-निष्क्रिय फेलओवर रूटिंग और सक्रिय-सक्रिय भारित रूटिंग दोनों का दस्तावेजीकरण करता है। यहाँ, सक्रिय-सक्रिय कोल्ड-फेलओवर जोखिम को कम करता है। स्वास्थ्य पदानुक्रमित (hierarchical) है: इंस्टेंस स्वास्थ्य एक प्रक्रिया को हटाता है, जोनल सिग्नल एक ज़ोन को खाली करते हैं, और सिंथेटिक एंड-टू-एंड जांच और क्षेत्रीय त्रुटि दरें एक क्षेत्र को हटा देती हैं। ट्रैफ़िक स्थानांतरण जब संभव हो क्रमिक होता है। क्षेत्रीय बैकएंड और उनके डेटा स्टोर भी तैयार होने चाहिए; केवल गेटवे को स्थानांतरित करने से कोई अनुपलब्ध सेवा स्वस्थ नहीं हो सकती।

ऑब्ज़र्वेबिलिटी के लिए गेटवे-अतिरिक्त p50/p95/p99 लेटेंसी, रूट द्वारा अनुरोध और त्रुटि दरें, TLS और प्रमाणीकरण विफलताएं, कोटा परिणाम, सक्रिय कनेक्शन, कतार की गहराई, पुनः प्रयास, सर्किट स्थिति, अपस्ट्रीम लेटेंसी, एंडपॉइंट स्वास्थ्य और कॉन्फ़िगरेशन-संस्करण अंतराल की आवश्यकता होती है। लॉग सफल ट्रैफ़िक का नमूना लेते हैं लेकिन एक सीमित बजट के तहत सुरक्षा और त्रुटि घटनाओं को बनाए रखते हैं। ट्रेसेस आने वाले संदर्भ को संरक्षित करते हैं और एक गेटवे स्पैन शुरू करते हैं। अलर्ट गेटवे विफलता को अपस्ट्रीम विफलता से अलग करते हैं ताकि ऑपरेटर किसी सेवा घटना के लिए स्वस्थ गेटवे को रोल बैक न करें।

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

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

उच्च-गुणवत्ता वाला नमूना उत्तर (High-Quality Sample Answer)

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

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

500,000 अनुरोध प्रति सेकंड पर, 2 KiB इनबाउंड डेटा ओवरहेड से पहले लगभग 0.95 GiB/s होता है। मैं सुरक्षित प्रति-इंस्टेंस थ्रूपुट Q प्राप्त करने के लिए पूर्ण नीति श्रृंखला का बेंचमार्क करूँगा और विफलता हेडरूम के साथ ceil(500,000 / Q) तैनात करूँगा। चूंकि तीन समान क्षेत्रों में से एक को खोने से प्रत्येक उत्तरजीवी का भार 50% बढ़ जाता है, इसलिए क्षेत्रीय क्षमता और लोड परीक्षणों में वह स्थिति शामिल होगी।

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

सामान्य गलतियाँ (Common Mistakes)

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

अनुवर्ती प्रश्न और उत्तर (Follow-up Questions and Responses)

अनुवर्ती 1: अनुरोधों को छोड़े बिना आप खराब रूट कॉन्फ़िगरेशन को कैसे वापस रोल करते हैं?

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

अनुवर्ती 2: यदि कंट्रोल प्लेन एक घंटे के लिए अनुपलब्ध हो तो क्या होगा?

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

अनुवर्ती 3: गेटवे द्वारा पुनः प्रयास करने पर आप POST को डुप्लिकेट करने से कैसे बचते हैं?

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

अनुवर्ती 4: क्या आप क्षेत्रीय रूटिंग के लिए ग्लोबल DNS या एनीकास्ट चुनेंगे?

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

अनुवर्ती 5: आपको एक गेटवे को कई गेटवे में कब विभाजित करना चाहिए?

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