प्रॉम्प्ट और संदर्भ
एक रियल-टाइम सहयोग सेवा में थर्ड-पार्टी WebSocket लाइब्रेरी का उपयोग करने वाले हज़ारों लंबे समय तक चलने वाले (long-lived) कनेक्शन्स हैं। Node.js 22.4 WebSocket को स्टेबल चिह्नित करता है, और टीम डिपेंडेंसी कम करना चाहती है। कम्पैटिबिलिटी, लाइफसाइकिल, बैकप्रेशर, ऑथेंटिकेशन, ऑब्जर्वेबिलिटी और रोलबैक को कवर करें।
इंटरव्यूअर क्या टेस्ट कर रहे हैं
वे जाँच रहे हैं कि क्या आप API स्थिरता को प्रोडक्शन परिपक्वता से अलग पहचानते हैं, और क्या आप सीमाएं (limits), हार्टबीट्स, ब्रॉडकास्ट बैकप्रेशर, ग्रेसफुल शटडाउन और एक नपे-तुले माइग्रेशन को डिज़ाइन कर सकते हैं।
स्पष्ट करने वाले प्रश्न
क्लाइंट प्रोटोकॉल, प्रॉक्सी सपोर्ट, मैसेज साइज़, पीक कनेक्शन्स, क्रेडेंशियल रिन्यूअल, क्रॉस-नोड फैन-आउट, पुनः कनेक्शन (reconnects) और क्षेत्रीय विफलताओं के बारे में पूछें। एक्सटेंशन व्यवहार और उन गारंटियों की पहचान करें जिन्हें वर्तमान लाइब्रेरी को बनाए रखना चाहिए।
30-सेकंड का उत्तर
"मैं एक API और प्रोटोकॉल अंतर मैट्रिक्स बनाऊंगा और Node 22.4+, प्रॉक्सी और क्लाइंट्स को सत्यापित करूंगा। प्रत्येक कनेक्शन को ऑथ, हार्टबीट, आइडल और मैसेज-साइज़ सीमाएं मिलती हैं; ब्रॉडकास्ट बैकप्रेशर के लिए बाउंडेड कतारों (bounded queues) का उपयोग करते हैं, और शटडाउन नए कनेक्शन अस्वीकार करने के बाद ड्रेन करता है। मैं शैडो और कैनरी करूंगा, हैंडशेक सफलता, डिस्कनेक्ट्स, P95 लेटेंसी, मेमोरी और CPU की तुलना करूंगा, और तेज़ रोलबैक के लिए थर्ड-पार्टी कार्यान्वयन पर लौटने के लिए एक स्विच रखूंगा।"
चरण-दर-चरण गहन विश्लेषण
रनटाइम और प्रोटोकॉल सत्यापित करें
Node दस्तावेज़ीकरण कहता है कि WebSocket v22.4.0 से प्रायोगिक (experimental) नहीं रहा है। Node वर्ज़न को लॉक करें और हैंडशेक, एक्सटेंशन, प्रॉक्सी टाइमआउट और TLS सेटिंग्स को सत्यापित करें।
कनेक्शन लाइफसाइकिल डिज़ाइन करें
कनेक्ट समय पर ऑथेंटिकेट और ऑथराइज़ करें, फिर आइडल, हार्टबीट और क्लोज़-कोड नीतियां निर्धारित करें। रीस्टार्ट के दौरान, कनेक्शन स्वीकार करना बंद करें, ड्रेन करें और पुनः कनेक्ट करने का संकेत भेजें।
बैकप्रेशर और साइज़ संभालें
प्रत्येक कनेक्शन को एक बाउंडेड सेंड कतार दें। सीमा पार होने पर, पुनः निर्माण योग्य मैसेजेस को ड्रॉप करें, डिग्रेड करें या धीमे उपभोक्ताओं को डिस्कनेक्ट करें। फ्रेम्स और एकत्रित मैसेजेस की सीमा तय करें ताकि एक क्लाइंट मेमोरी या इवेंट लूप को समाप्त न कर दे।
ऑथेंटिकेशन और ऑथराइजेशन लागू करें
हैंडशेक के दौरान कम समय के क्रेडेंशियल को मान्य करें और संवेदनशील संदेशों के लिए टेनेंट और रिसोर्स अनुमतियों की पुनः जाँच करें। विफल रिन्यूअल कनेक्शन को बंद कर देता है और पुनः ऑथेंटिकेशन की आवश्यकता होती है।
नोड्स में स्केल करें
कनेक्शन स्थिति को स्थानीय रखें और इवेंट्स को मैसेज बस के माध्यम से रूट करें। सब्सक्रिप्शन्स को एक वर्ज़न या कर्सर दें ताकि पुनः कनेक्ट होने पर सब कुछ फिर से ब्रॉडकास्ट करने के बजाय छूटे हुए अंतराल (gaps) को फिर से चलाया जा सके।
कैनरी, मॉनिटर और रोल बैक करें
आंतरिक रूप से और 1% ट्रैफ़िक के लिए सक्षम करें। हैंडशेक विफलताओं, कनेक्शन उत्तरजीविता, पुनः कनेक्शन, कतार ड्रॉप्स, P95 लेटेंसी, मेमोरी और CPU की तुलना करें। पुराने कार्यान्वयन को स्विच करने योग्य रखें और प्रोटोकॉल या संसाधन प्रतिगमन (regressions) पर वापस लौटें।
आदर्श उत्तर
मैं केवल इसलिए लाइब्रेरी को नहीं बदलूंगा क्योंकि API स्टेबल है। मैं Node 22.4+, प्रॉक्सी और क्लाइंट कम्पैटिबिलिटी को लॉक करूंगा, फिर हैंडशेक ऑथ, हार्टबीट, आइडल टाइमआउट, साइज़ कैप्स और बाउंडेड सेंड कतारें जोड़ूंगा। नोड्स इवेंट्स और कर्सर साझा करते हैं, कनेक्शन स्थिति नहीं, और पुनः कनेक्शन अंतराल को रीप्ले करते हैं। एक कैनरी हैंडशेक सफलता, डिस्कनेक्ट्स, पुनः कनेक्शन, कतार ड्रॉप्स, P95, मेमोरी और CPU की तुलना करता है जबकि पुराना पथ रोलबैक के लिए उपलब्ध रहता है।
सामान्य गलतियाँ
स्टेबल API को पूर्ण प्रतिस्थापन के समान मानना
लाइब्रेरी एक्सटेंशन, कम्प्रेशन या पुनः कनेक्ट व्यवहार प्रदान कर सकती है। प्रत्येक अंतर का दस्तावेजीकरण करें और उसका परीक्षण करें।
धीमे उपभोक्ता की नीति को छोड़ना
असीमित कतारें मेमोरी समाप्त कर देती हैं। कतार को बाउंड करें, पुनः निर्माण योग्य संदेशों को ड्रॉप करें, या डिस्कनेक्ट करें।
केवल हैंडशेक पर ऑथराइज़ करना
लंबे कनेक्शन के दौरान अनुमतियां रद्द की जा सकती हैं। संवेदनशील क्रियाओं के लिए मैसेज-स्तरीय जांच या नीति संस्करण की आवश्यकता होती है।
रीस्टार्ट के दौरान कनेक्शन्स को तुरंत समाप्त करना
इससे पुनः कनेक्शन का तूफ़ान (reconnect storm) आता है। ड्रेन करें, पुनः कनेक्शन में जिटर जोड़ें, और स्पष्ट क्लोज़ कोड का उपयोग करें।
आगे के प्रश्न
आप पुनः कनेक्शन के तूफ़ान को कैसे नियंत्रित करते हैं?
एक स्पष्ट क्लोज़ कारण लौटाएं, क्लाइंट्स में जिटर के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करें, और सर्वर पर IP, टेनेंट और अकाउंट द्वारा दर सीमित (rate-limit) करें।
आप थर्ड-पार्टी लाइब्रेरी को कब बनाए रखेंगे?
इसे तब बनाए रखें जब आवश्यक एक्सटेंशन, कम्प्रेशन, प्रॉक्सी कम्पैटिबिलिटी या परिपक्व टेलीमेट्री मेल न खाते हों और प्रतिस्थापन का मूल्य कम हो; मूल्यांकन सीमा को रिकॉर्ड करें।
आप बैकप्रेशर का परीक्षण कैसे करते हैं?
धीमे क्लाइंट्स और बर्स्ट ब्रॉडकास्ट्स इंजेक्ट करें, फिर कतार सीमा, ड्रॉप व्यवहार, इवेंट-लूप विलंब और मेमोरी वक्रों का निरीक्षण करें।
आप नोड्स में ऑर्डर कैसे बनाए रखते हैं?
प्रति सब्सक्रिप्शन स्ट्रीम एक मोनोटोनिक कर्सर असाइन करें और बस के माध्यम से वर्ज़न ले जाएं; क्लाइंट्स अंतराल का पता लगाते हैं और रीप्ले का अनुरोध करते हैं।