संकेत और उपयुक्त संदर्भ
यह एक सिस्टम-डिज़ाइन प्रश्न है। इसका मुख्य उद्देश्य URL या हेडर वर्ज़न चुनना नहीं है; बल्कि एक API जीवनचक्र कंट्रोल प्लेन डिज़ाइन करना है। एक कॉन्ट्रैक्ट परिवर्तन का प्रभाव विश्लेषण, वास्तविक-कंज़्यूमर खोज, पुराने/नए व्यवहार की जांच, चरणबद्ध माइग्रेशन और साक्ष्य-आधारित शटडाउन में रूपांतरण होना चाहिए। Microsoft जब संभव हो बैकवर्ड कम्पैटिबिलिटी बनाए रखने की सलाह देता है, और Google Cloud भी इसी तरह पहले कम्पैटिबल इवोल्यूशन आज़माने की सलाह देता है। इंटरव्यू आपसे उन सिद्धांतों को एक ऐसे सिस्टम में बदलने के लिए कहता है जो सभी टीमों में काम करे।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप फॉर्मेट कम्पैटिबिलिटी, एंटिटी-सिमेंटिक परिवर्तनों और वास्तव में ब्रेकिंग परिवर्तनों के बीच अंतर करते हैं।
- क्या आप API कॉन्ट्रैक्ट्स, कंज़्यूमर इन्वेंट्री, रनटाइम ट्रैफ़िक और माइग्रेशन कार्य को आपस में जोड़ते हैं।
- क्या आप केवल वर्ज़न लेबल्स के बजाय कम्पैटिबिलिटी परीक्षण, क्रमिक रोलआउट, अलर्ट, नोटिस और रोलबैक डिज़ाइन करते हैं।
- क्या आप एकाधिक वर्ज़न की परिचालन लागत, डेटा-रूपांतरण जोखिम और संगठनात्मक सीमाओं की व्याख्या कर सकते हैं।
पहले पूछे जाने वाले स्पष्टीकरण
पुष्टि करें कि API आंतरिक है, पार्टनर-फ़ेसिंग है, या सार्वजनिक है; क्या कंज़्यूमर्स की पूरी तरह से पहचान की जा सकती है; और ट्रैफ़िक, लेटेंसी और उपलब्धता के लक्ष्य क्या हैं। स्पष्ट करें कि क्या फ़ील्ड वैकल्पिक है, क्या इसका अर्थ बदलता है, और क्या इसमें रीड, राइट, या परसिस्टेड डेटा शामिल है। OpenAPI या किसी अन्य कॉन्ट्रैक्ट स्रोत, क्लाइंट SDKs, नोटिस चैनल, सहायता विंडो, अनुपालन आवश्यकताओं और रोलबैक अवधि के बारे में पूछें। यदि स्केल अनिर्दिष्ट है, तो अपनी धारणाएं बताएं।
30-सेकंड का उत्तर ढांचा
मैं पांच चरणों को डिज़ाइन करूंगा: कॉन्ट्रैक्ट रजिस्ट्री, इम्पैक्ट डिस्कवरी, कम्पैटिबिलिटी वैलिडेशन, माइग्रेशन कोऑर्डिनेशन और शटडाउन साक्ष्य। प्रत्येक API कॉन्ट्रैक्ट एक रजिस्ट्री में जाता है; एक नियम इंजन परिवर्तनों को वर्गीकृत करता है, फिर कंज़्यूमर्स की पहचान करने के लिए स्टैटिक डिपेंडेंसी और रनटाइम कॉल्स को जोड़ता है। पुराने और नए वर्ज़न समानांतर में चलते हैं जबकि कंज़्यूमर्स को समय सीमा और माइग्रेशन गाइड के साथ नोटिस प्राप्त होते हैं। क्रमिक रोलआउट के दौरान, वर्ज़न के अनुसार सफलता, त्रुटियां और अवशिष्ट ट्रैफ़िक रिकॉर्ड करें। केवल महत्वपूर्ण कंज़्यूमर्स के माइग्रेट होने, माइग्रेशन साक्ष्य पूरा होने, रोलबैक का अभ्यास होने और एक ओनर द्वारा परिवर्तन को मंज़ूरी दिए जाने के बाद ही शटडाउन करें।
चरण-दर-चरण विस्तृत उत्तर
1. एक कॉन्ट्रैक्ट रजिस्ट्री और परिवर्तन नियम बनाएं
रजिस्ट्री प्रत्येक API, वर्ज़न, ओनर, फ़ील्ड सिमेंटिक्स, ऑथेंटिकेशन स्कोप, सपोर्ट स्थिति, डेप्रिकेशन तिथि और माइग्रेशन दस्तावेज़ को संग्रहीत करती है। एक परिवर्तन अनुरोध में एक कॉन्ट्रैक्ट डिफ शामिल होता है, और नियम इंजन हटाए गए फ़ील्ड, संकुचित किए गए enums, बदली गई आवश्यकता, परिवर्तित त्रुटि सिमेंटिक्स और एंटिटी संबंध परिवर्तनों को चिह्नित करता है। एक इग्नोर करने योग्य फ़ील्ड जोड़ना अक्सर कम्पैटिबल होता है, लेकिन यह नहीं माना जा सकता कि क्लाइंट अज्ञात फ़ील्ड्स को सही ढंग से अनदेखा करेंगे; टीमों को साक्ष्य-समर्थित अपवाद पथ की आवश्यकता होती है।
2. कंज़्यूमर्स की खोज करें और एक इम्पैक्ट ग्राफ़ बनाएं
रिपॉजिटरी डिपेंडेंसी, गेटवे लॉग्स, सर्विस-मेश टेलीमेट्री, SDK पंजीकरण और घोषणाओं को एक API-वर्ज़न-कंज़्यूमर ग्राफ़ में संयोजित करें। स्टैटिक खोज गतिशील रूप से निर्मित अनुरोधों से चूक सकती है, जबकि रनटाइम खोज दुर्लभ जॉब्स से चूक सकती है, इसलिए साक्ष्य स्रोत, अंतिम बार देखे जाने का समय और विश्वास स्तर को चिह्नित करें। बाहरी क्लाइंट्स के लिए, लॉग्स को अनिश्चितकालीन व्यक्तिगत डेटा के रूप में मानने के बजाय केवल आवश्यक टेनेंट और एप्लिकेशन पहचानकर्ताओं को बनाए रखें।
3. सुरक्षा द्वारों के साथ कम्पैटिबिलिटी सत्यापित करें
प्रत्येक परिवर्तन के लिए, कॉन्ट्रैक्ट परीक्षण, कंज़्यूमर रीप्ले और सैंपल किए गए ट्रैफ़िक की तुलना करें। रीड्स पर रिस्पॉन्स सिमेंटिक्स की जांच करें और सत्यापित करें कि पुराने क्लाइंट राइट्स डेटा नहीं खोते हैं या अनपेक्षित दुष्प्रभाव उत्पन्न नहीं करते हैं। शैडो ट्रैफ़िक या एक छोटे टेनेंट कोहोर्ट में ब्रेकिंग बदलाव शुरू करें; वर्ज़न रूटिंग और फीचर फ़्लैग्स को रिवर्ट करने योग्य होना चाहिए। अप्रयुक्त कंज़्यूमर्स के लिए एक उत्तीर्ण परीक्षण सेट को प्रमाण मानने के बजाय विफलता पर पुराने वर्ज़न को बनाए रखें।
4. नोटिस, माइग्रेशन और मल्टी-वर्ज़न संचालन का समन्वय करें
एक नोटिस सेवा कंज़्यूमर, गंभीरता और सपोर्ट अनुबंध के आधार पर माइग्रेशन गाइड, समय सीमा, उदाहरण अनुरोध और संपर्क भेजती है; बाहरी ग्राहकों को एक क्वेरी योग्य स्थिति पृष्ठ या कंसोल की आवश्यकता होती है। माइग्रेशन कार्य में एक ओनर, ब्लॉकर्स, सत्यापन साक्ष्य और अंतिम सफल कॉल दर्ज होती है। एकाधिक वर्ज़न परीक्षण, डिप्लॉयमेंट और निगरानी लागत जोड़ते हैं, इसलिए प्रत्येक वर्ज़न को अनिश्चित काल तक सपोर्ट करने के बजाय एक वर्ज़न सीमा, डेप्रिकेशन चरण और एक माइग्रेशन पथ निर्धारित करें।
5. शटडाउन तय करें, निरीक्षण करें और पुनर्प्राप्त करें
शटडाउन से पहले, सत्यापित करें कि महत्वपूर्ण कंज़्यूमर्स अपग्रेड हो गए हैं, अवशिष्ट कॉल सीमा से नीचे हैं, कोई त्रुटि प्रतिगमन नहीं है, प्रतिवर्ती डेटा रूपांतरण है, और सहायता तत्परता है। कोहोर्ट्स और समय सीमाओं का उपयोग करें: नए ऑनबोर्डिंग को रोकें, पुरानी कॉलों को एक स्पष्ट डेप्रिकेशन त्रुटि और माइग्रेशन लिंक वापस करें, फिर रूटिंग अक्षम करें। कम्पैटिबिलिटी विफलताओं, पुराने-वर्ज़न ट्रैफ़िक, माइग्रेशन पूर्णता, नोटिस डिलीवरी, रोलबैक गणना और कंज़्यूमर-खंडित त्रुटियों को ट्रैक करें। Kubernetes दिखाता है कि कैसे स्थिरता स्तर, न्यूनतम सपोर्ट अवधि, रूपांतरण और रोलबैक बाधाएं स्पष्ट नीति हो सकती हैं; संगठन के लिए ऐसी बाधाओं को कॉन्फ़िगर करें न कि इसकी तिथियों को सार्वभौमिक रूप से कॉपी करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं कंज़्यूमर के प्रकार, कॉन्ट्रैक्ट स्रोत, हटाए जा रहे फ़ील्ड के रीड/राइट सिमेंटिक्स, बाहरी नोटिस दायित्वों और रोलबैक अवधि को स्पष्ट करूंगा। एक कॉन्ट्रैक्ट रजिस्ट्री एक परिवर्तन-नियम इंजन को फ़ीड करती है जो ब्रेकिंग अंतरों की पहचान करता है और उन्हें कोड डिपेंडेंसी, गेटवे लॉग्स और सर्विस-मेश टेलीमेट्री से निर्मित एक इम्पैक्ट ग्राफ़ से जोड़ता है, जिसमें साक्ष्य की ताजगी शामिल होती है। कम्पैटिबिलिटी परीक्षण, कंज़्यूमर रीप्ले और क्रमिक ट्रैफ़िक पुराने और नए व्यवहार को मान्य करते हैं; एक नोटिस सेवा प्रत्येक कंज़्यूमर को एक माइग्रेशन गाइड और समय सीमा भेजती है। वर्ज़न समानांतर में चलते हैं, और माइग्रेशन कार्य सत्यापन साक्ष्य संग्रहीत करता है। केवल महत्वपूर्ण कंज़्यूमर्स के माइग्रेट होने के बाद, अवशिष्ट ट्रैफ़िक और त्रुटियों के सीमा को पूरा करने, रोलबैक का अभ्यास होने और एक ओनर द्वारा मंज़ूरी मिलने के बाद ही हम पुराने रूट को रिटायर करते हैं। ऑडिट लॉग्स परिवर्तनों, नोटिसों, अवलोकनों और रोलबैक को कवर करते हैं ताकि अज्ञात क्लाइंट्स अचानक बंद न हों।
सामान्य गलतियां
- कंज़्यूमर खोज और शटडाउन साक्ष्य के बिना URL, हेडर, या सिमेंटिक-वर्ज़न लेबल्स पर बहस करना।
- गतिशील और दुर्लभ कॉलों को छोड़ते हुए केवल स्टैटिक कोड खोज या एक एक्सेस लॉग पर निर्भर रहना।
- वास्तविक क्लाइंट पार्सिंग का परीक्षण किए बिना यह मान लेना कि किसी वैकल्पिक फ़ील्ड को हटाना स्वतः सुरक्षित है।
- क्रमिक रोलआउट या रोलबैक के बिना नया वर्ज़न लॉन्च करना और पुराने को तुरंत बंद करना।
- परीक्षण, निगरानी और रूपांतरण लागत का मूल्यांकन किए बिना प्रत्येक वर्ज़न को हमेशा के लिए सपोर्ट करना।
- बिना किसी समय सीमा, ओनर, एस्केलेशन पथ, या खंडित मेट्रिक्स के सिर्फ एक ईमेल भेजना।
फॉलो-अप प्रश्न और उत्तर
जब कोई बाहरी क्लाइंट नहीं मिल पाता है तो आप शटडाउन का निर्णय कैसे लेते हैं?
अज्ञात उपयोग को एक जोखिम स्थिति के रूप में मानें, अवलोकन विंडो का विस्तार करें, टेलीमेट्री बढ़ाएं, और संविदात्मक ओनर से संपर्क करें या एक माइग्रेशन डायग्नोस्टिक की पेशकश करें। शून्य लॉग शून्य उपयोग को साबित नहीं करता है; शटडाउन से पहले एक पुनर्प्राप्त करने योग्य अस्वीकृति नीति और आपातकालीन फ़ॉलबैक का उपयोग करें।
क्या रिस्पॉन्स फ़ील्ड जोड़ना हमेशा कम्पैटिबल होता है?
नहीं। नियम इसे आमतौर पर कम्पैटिबल के रूप में वर्गीकृत कर सकते हैं, लेकिन वास्तविक कंज़्यूमर रीप्ले, SDK मैट्रिस और त्रुटि नमूनों को अभी भी इसे मान्य करने की आवश्यकता है। सख्त स्कीमा वैलिडेटर्स को एक अलग माइग्रेशन या वर्ज़न सीमा की आवश्यकता हो सकती है।
आप पुराने क्लाइंट्स द्वारा लिखे गए डेटा को सुरक्षित रूप से कैसे माइग्रेट करते हैं?
पहले सिमेंटिक मैपिंग और नो-लॉस शर्तों को परिभाषित करें, फिर वर्ज़न रिकॉर्ड के साथ डुअल रीड, डुअल राइट या ऑफ़लाइन रूपांतरण का उपयोग करें। रूपांतरण सत्यापन योग्य और प्रतिवर्ती होना चाहिए; रीड टाइम पर व्यावसायिक अर्थ को चुपचाप न बदलें।
क्या होगा यदि कोई ग्राहक समय सीमा तक अपग्रेड नहीं कर पाता है?
अनुबंध और जोखिम के अनुसार एक सीमित कम्पैटिबिलिटी विंडो, एडॉप्टर, या सहायता प्राप्त माइग्रेशन की पेशकश करें, जिसमें लागत, ओनर और एक नई निकास तिथि दर्ज हो। अपवादों को पुराने वर्ज़न को स्थायी बनाने के बजाय अज्ञात ट्रैफ़िक को कम करना चाहिए।
आप कंट्रोल प्लेन को सिंगल पॉइंट ऑफ़ फ़ेलियर बनने से कैसे बचाते हैं?
डेटा-प्लेन रूटिंग को लाइव कंट्रोल-प्लेन राइट की आवश्यकता नहीं होनी चाहिए। अनुमोदित वर्ज़न नीति को कैश करें और कंट्रोल-प्लेन विफलता के दौरान अंतिम सुरक्षित कॉन्फ़िगरेशन को बनाए रखें। रजिस्ट्री, नोटिस और मेट्रिक सेवाएं एसिंक्रोनस रूप से पुनर्प्राप्त हो सकती हैं, जबकि शटडाउन के लिए दोहरी मंज़ूरी और स्पष्ट रोलबैक की आवश्यकता होती है।