प्रॉम्प्ट और दायरा
इसे डेटा-इंजीनियरिंग डिज़ाइन प्रश्न के रूप में लें। पीक पर प्रति सेकंड 2,000 ऑर्डर इवेंट्स, 15 मिनट का फ्रेशनेस लक्ष्य और आवश्यक फ़ील्ड्स के लिए 99.5% पूर्णता (completeness) का लक्ष्य मानकर चलें। कॉन्ट्रैक्ट में संरचना, अर्थ, गुणवत्ता, सेवा स्तर (service levels), ओनरशिप, प्राइवेसी टैग्स और किसी भी वादे को बदलने की प्रक्रिया शामिल होनी चाहिए।
उपयोगी सीमा अपस्ट्रीम प्रोड्यूसर और डाउनस्ट्रीम कंज्यूमर्स के बीच का डेटा प्रोडक्ट है। केवल एक डेटाबेस टेबल की परिभाषा बहुत संकीर्ण है: यह यह नहीं बता सकती कि total_amount में टैक्स शामिल है या नहीं, फ़ीड का मालिक कौन है, या फ्रेशनेस मिस होने पर क्या होता है।
इंटरव्यूअर क्या टेस्ट कर रहा है
इंटरव्यूअर एक ऐसा कॉन्ट्रैक्ट सुनना चाहता है जो निष्पादन योग्य (executable), वर्ज़न-युक्त और ओनरशिप वाला हो। एक कमज़ोर उत्तर सिर्फ Avro या JSON Schema की सूची देता है। एक मजबूत उत्तर कम्पैटिबिलिटी को सेमेंटिक शुद्धता से अलग करता है, प्रोड्यूसर की सीमा पर जाँच लागू करता है, और कंज्यूमर्स को एक पूर्वानुमेय उल्लंघन और माइग्रेशन पाथ प्रदान करता है।
आपको प्रत्येक फ़ील्ड को एक कंज्यूमर निर्णय से जोड़ना चाहिए: रिजेक्ट करना, क्वारंटीन करना, ट्रांसफ़ॉर्म करना, अलर्ट भेजना, या स्पष्ट रूप से डिग्रेडेड स्थिति के साथ जारी रखना। आपको यह भी समझाना चाहिए कि कॉन्ट्रैक्ट एक अनडॉक्युमेंटेड अप्रूवल कतार बनने से कैसे बचता है।
स्पष्टीकरण जो डिज़ाइन को बदलते हैं
- क्या स्रोत केवल-जोड़ने योग्य (append-only) इवेंट स्ट्रीम है, म्यूटेबल टेबल है, या दोनों? म्यूटेबल स्नैपशॉट्स के लिए कीज़, अपडेट सेमेंटिक्स और डिलीशन रूल्स की आवश्यकता होती है।
- कौन सी गारंटी सख्त लॉन्च गेट्स हैं? एक पेमेंट इवेंट अमान्य मुद्रा पर रिजेक्ट हो सकता है, जबकि एक वैकल्पिक मार्केटिंग लेबल को क्वारंटीन किया जा सकता है।
- क्या कंज्यूमर्स एक वर्ज़न पीछे रह सकते हैं? यदि हाँ, तो एक कम्पैटिबिलिटी विंडो और ट्रांसफ़ॉर्मेशन पब्लिश करें; यदि नहीं, तो एक समन्वित कटओवर की आवश्यकता होगी।
- क्या इवेंट्स को दोबारा चलाया जा सकता है (replayable) और क्या उनमें व्यक्तिगत डेटा शामिल है? रिप्लेएबिलिटी डेटा रिटेंशन को प्रभावित करती है, और प्राइवेसी टैग्स मास्किंग, एक्सेस और डिलीशन हैंडलिंग को प्रभावित करते हैं।
30-सेकंड का उत्तर ढाँचा
"मैं कंज्यूमर के उपयोग के मामलों (use cases) से शुरुआत करूँगा और एक वर्ज़न-युक्त, मशीन-पठनीय कॉन्ट्रैक्ट लिखूँगा। यह स्कीमा और सेमेंटिक्स, आवश्यक फ़ील्ड और डोमेन चेक्स, फ्रेशनेस और पूर्णता के SLOs, ओनरशिप, प्राइवेसी टैग्स और एक इवोल्यूशन नीति को परिभाषित करेगा। प्रोड्यूसर्स पब्लिश करने से पहले वेलिडेट करते हैं; रजिस्ट्री CI में कम्पैटिबिलिटी की जाँच करती है; रनटाइम चेक्स खराब रिकॉर्ड्स को क्वारंटीन करते हैं और मेट्रिक्स प्रदर्शित करते हैं। एक नया वर्ज़न डिफ़ॉल्ट रूप से एडिटिव होता है, जिसमें ब्रेकिंग सेमेंटिक परिवर्तनों के लिए डुअल-पब्लिश या ट्रांसफ़ॉर्मेशन विंडो होती है। प्रत्येक उल्लंघन का एक ओनर, रिप्ले पाथ और कंज्यूमर को दिखाई देने वाला स्टेटस होता है।"
चरण-दर-चरण डिज़ाइन
1. कॉन्ट्रैक्ट ऑब्जेक्ट को परिभाषित करें
डेटासेट को एक पहचानकर्ता (identifier) और वर्ज़न दें। प्रत्येक फ़ील्ड के लिए रिकॉर्ड का प्रकार, नलेबिलिटी (nullability), यूनिट, व्यावसायिक अर्थ, अनुमत मान, संवेदनशीलता, और क्या अज्ञात फ़ील्ड्स की अनुमति है, यह दर्ज करें। ऑर्डर इवेंट के लिए, बताएं कि क्या occurred_at इवेंट का समय है, क्या राशियां पूर्णांक माइनर यूनिट्स हैं, और क्या रद्द किया गया ऑर्डर दृश्यमान रहता है।
ओनरशिप, सपोर्ट संपर्क, रिटेंशन, फ्रेशनेस, डिलीवरी फ्रीक्वेंसी और उपलब्धता जोड़ें। एक सेवा स्तर मापने योग्य होता है: फ्रेशनेस नवीनतम स्वीकृत रिकॉर्ड की आयु हो सकती है, जबकि पूर्णता एक विंडो में गैर-शून्य आवश्यक फ़ील्ड्स का अनुपात हो सकती है।
2. विफलता मोड के आधार पर चेक्स को अलग करें
स्कीमा चेक्स गायब फ़ील्ड्स और असंगत प्रकारों को पकड़ते हैं। डोमेन चेक्स शून्य से कम राशि या असमर्थित मुद्रा को पकड़ते हैं। रिलेशनल चेक्स डुप्लिकेट इवेंट IDs या ऐसे ऑर्डर ट्रांज़िशन को पकड़ते हैं जो किसी आवश्यक स्थिति को छोड़ देता है। फ्रेशनेस और वॉल्यूम चेक्स रुके हुए प्रोड्यूसर या आंशिक पार्टीशन को पकड़ते हैं।
टेस्ट परिणाम को कॉन्ट्रैक्ट वर्ज़न, प्रोड्यूसर बिल्ड, पार्टीशन, सैंपल विंडो और विफल नियम के साथ रखें। वह साक्ष्य एक कंज्यूमर को यह तय करने की अनुमति देता है कि क्या रुकना है, बैकफ़िल करना है, या एक सीमित गिरावट (bounded degradation) को स्वीकार करना है।
3. पब्लिश करने से पहले और बाद में लागू करें
CI में, प्रस्तावित स्कीमा की तुलना रजिस्टर्ड वर्ज़न से करें और प्रतिनिधि कॉन्ट्रैक्ट टेस्ट्स चलाएं। रनटाइम पर, इवेंट के शेयर्ड स्ट्रीम में प्रवेश करने से पहले प्रोड्यूसर की सीमा पर वेलिडेट करें। अमान्य रिकॉर्ड्स को मूल पेलोड, नियम विफलताओं, कॉन्ट्रैक्ट वर्ज़न और एक रिप्ले की (replay key) के साथ क्वारंटीन स्ट्रीम में भेजें।
कंज्यूमर्स को अभी भी अपनी सीमा पर महत्वपूर्ण इनवेरिएंट्स (invariants) को वेलिडेट करना चाहिए। प्रोड्यूसर प्रवर्तन कई घटनाओं को रोकता है; कंज्यूमर चेक्स गलत कॉन्फ़िगर किए गए रूट्स, पुराने प्रोड्यूसर्स और ट्रांसफ़ॉर्मेशन बग्स से रक्षा करते हैं।
4. इवोल्यूशन को स्पष्ट बनाएं
एक वैकल्पिक फ़ील्ड जोड़ने को केवल तभी कम्पैटिबिलिटी बनाए रखने वाला बदलाव मानें जब पुराने कंज्यूमर्स अज्ञात फ़ील्ड्स को सहन करते हों। नाम बदलना (rename) ब्रेकिंग होता है क्योंकि अर्थ या फ़ील्ड का नाम बदल जाता है। 'जोड़ें और अप्रचलित करें' (add-and-deprecate) को प्राथमिकता दें: नया फ़ील्ड पब्लिश करें, डुअल-राइट या ट्रांसफ़ॉर्म करें, कंज्यूमर्स को माइग्रेट करें, पुराने फ़ील्ड के रीड्स को मापें, फिर एक निर्धारित विंडो के बाद इसे रिटायर करें।
सेमेंटिक बदलाव के लिए, जैसे total_amount को टैक्स-सहित से टैक्स-रहित में बदलना, नाम का पुन: उपयोग करने की तुलना में एक नया वर्ज़न और नया फ़ील्ड अधिक सुरक्षित है। यदि किसी कंज्यूमर को पुराने व्यू पर ही रहना है, तो एक वर्ज़न-युक्त ट्रांसफ़ॉर्मेशन का उपयोग करें और कनवर्ट किए गए मान को लेबल करें।
5. उल्लंघन प्रबंधन को परिभाषित करें
गंभीरता स्तरों (severity tiers) का उपयोग करें। एक विकृत (malformed) पेमेंट इवेंट को अस्वीकार कर क्वारंटीन कर दिया जाता है। फ्रेशनेस का उल्लंघन ओनर को पेज करता है और डेटा प्रोडक्ट को स्टेल (बासी) के रूप में चिह्नित करता है। एक गैर-महत्वपूर्ण विवरण की विफलता एक मीट्रिक के साथ जारी रह सकती है। कॉन्ट्रैक्ट में यह उल्लेख होना चाहिए कि कौन किसी गेट को ओवरराइड कर सकता है, कितने समय के लिए, और किस साक्ष्य की आवश्यकता है।
रिकॉर्ड्स को चुपचाप ड्रॉप न करें। प्रोड्यूसर और कॉन्ट्रैक्ट वर्ज़न द्वारा स्वीकृत, अस्वीकृत, क्वारंटीन, रिप्ले किए गए और डुप्लिकेट काउंट्स को ट्रैक करें। एक रिप्ले को इडेम्पोटेंट होना चाहिए, ताकि सिंक दूसरा व्यावसायिक प्रभाव पैदा करने से बचने के लिए इवेंट ID और कॉन्ट्रैक्ट वर्ज़न का उपयोग करे।
6. ऑपरेटिंग मॉडल को सत्यापित करें
फिक्सचर डेटा पर कॉन्ट्रैक्ट टेस्ट्स, प्रत्येक प्रस्तावित वर्ज़न पर कम्पैटिबिलिटी टेस्ट्स, और सैंपल किए गए प्रोडक्शन पार्टीशन पर कैनरी वैलिडेशन चलाएं। देर से आने वाले इवेंट्स, डुप्लिकेट IDs, अज्ञात enum मान, रिक्त आवश्यक फ़ील्ड्स, टाइमज़ोन की गलतियाँ, और ऐसे प्रोड्यूसर का परीक्षण करें जो डेटा भेजना बंद कर देता है।
उपयोगी डैशबोर्ड उल्लंघन दर, फ्रेशनेस आयु, पूर्णता, कंज्यूमर लैग, क्वारंटीन गहराई, रिप्ले सफलता और ओनर की पावती (acknowledgement) तक के समय को जोड़ता है। स्टेल फ़ीड के साथ एक ग्रीन स्कीमा चेक अभी भी एक विफल डेटा प्रोडक्ट है।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं ऑर्डर स्ट्रीम को एक वर्ज़न-युक्त डेटा प्रोडक्ट के रूप में मानूँगा। मैं सबसे पहले कंज्यूमर्स को सूचीबद्ध करूँगा और इवेंट सेमेंटिक्स को परिभाषित करूँगा: इवेंट का समय, राशि की इकाइयाँ, मुद्रा, पहचान और स्थिति ट्रांज़िशन। इसके बाद कॉन्ट्रैक्ट में स्कीमा, डोमेन और रिलेशनल रूल्स, फ्रेशनेस और पूर्णता के SLOs, ओनरशिप, रिटेंशन और प्राइवेसी टैग्स शामिल होंगे।
रजिस्ट्री CI में असंगत परिवर्तनों को अस्वीकार करेगी। प्रोड्यूसर्स पब्लिश करने से पहले वेलिडेट करेंगे, जबकि एक रनटाइम वेलिडेटर खराब रिकॉर्ड्स को विफल नियम और कॉन्ट्रैक्ट वर्ज़न के साथ क्वारंटीन में भेजता है। कंज्यूमर्स महत्वपूर्ण चेक्स का एक छोटा सेट रखते हैं क्योंकि रूटिंग या ट्रांसफ़ॉर्मेशन अभी भी गलत हो सकता है।
मैं इवोल्यूशन को डिफ़ॉल्ट रूप से एडिटिव बनाऊँगा। नाम बदलने या सेमेंटिक परिवर्तन के लिए, मैं एक नया फ़ील्ड या वर्ज़न जोड़ूँगा, डुअल-पब्लिश करूँगा, कंज्यूमर्स को माइग्रेट करूँगा, पुराने-फ़ील्ड के रीड्स को मापूँगा, और कम्पैटिबिलिटी विंडो के बाद ही पुराने वर्ज़न को रिटायर करूँगा। फ्रेशनेस और गुणवत्ता उल्लंघनों की स्पष्ट गंभीरता, ओनर्स, अलर्ट्स और रिप्ले प्रक्रियाएं होंगी। मैं फिक्सचर्स, कैनरीज़, लेट और डुप्लिकेट इवेंट्स, और फ्रेशनेस, पूर्णता, क्वारंटीन गहराई और रिप्ले शुद्धता के मेट्रिक्स के साथ डिज़ाइन को सत्यापित करूँगा।"
सामान्य गलतियाँ
- गलती → विफलता → सुधार: केवल स्कीमा को पूरा कॉन्ट्रैक्ट कहना → सेमेंटिक परिवर्तन और ओनरशिप अस्पष्ट रह जाते हैं → अर्थ, SLOs, ओनर्स और परिवर्तन नीति का दस्तावेज़ीकरण करें।
- गलती → विफलता → सुधार: प्रत्येक अमान्य रिकॉर्ड को सिंक्रोनस रूप से अस्वीकार करना → एक खराब इवेंट पूरे पार्टीशन को ब्लॉक कर सकता है → सीमित बैकप्रेशर और रिप्ले की के साथ क्वारंटीन करें।
- गलती → विफलता → सुधार: यह दावा करना कि एडिटिव फ़ील्ड्स हमेशा सुरक्षित होते हैं → सख्त कंज्यूमर्स अज्ञात फ़ील्ड्स पर विफल हो सकते हैं → परिवर्तन की अनुमति देने से पहले कंज्यूमर कम्पैटिबिलिटी सत्यापित करें।
- गलती → विफलता → सुधार: केवल स्कीमा बेमेल पर अलर्ट करना → स्टेल या अधूरा डेटा अभी भी स्कीमा चेक्स को पास कर सकता है → फ्रेशनेस, वॉल्यूम, पूर्णता और व्यावसायिक इनवेरिएंट्स की निगरानी करें।
- गलती → विफलता → सुधार: अर्थ बदलने के बाद फ़ील्ड नाम का पुन: उपयोग करना → ऐतिहासिक और नए मान अतुलनीय हो जाते हैं → एक नया वर्ज़न या स्पष्ट रूप से ट्रांसफ़ॉर्म किया गया फ़ील्ड बनाएं।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि सभी प्रोड्यूसर्स एक साथ अपग्रेड नहीं कर सकते हैं?
पुराने कॉन्ट्रैक्ट को सक्रिय रखें, नया फ़ील्ड या वर्ज़न जोड़ें, और एक मापी गई विंडो के दौरान दोनों को स्वीकार करें। एक कम्पैटिबिलिटी एडाप्टर पुराने इनपुट का अनुवाद कर सकता है, लेकिन इसे अंतर को छिपाने के बजाय रूपांतरण हानि (conversion loss) और रिटायरमेंट की तारीख को उजागर करना चाहिए।
क्या होगा यदि कॉन्ट्रैक्ट टेस्ट पास हो जाता है लेकिन मीट्रिक अभी भी गलत है?
यह सेमेंटिक ड्रिफ्ट है। एक व्यावसायिक स्तर का इनवेरिएंट या समाधान (reconciliation) चेक जोड़ें, एक स्वतंत्र स्रोत से तुलना करें, और कॉन्ट्रैक्ट में विवादित परिभाषा दर्ज करें। संरचनात्मक कम्पैटिबिलिटी यह साबित नहीं कर सकती कि प्रोड्यूसर ने सही व्यावसायिक नियम लागू किया है।
आप क्वारंटीन को डेटा का कब्रिस्तान बनने से कैसे रोकते हैं?
प्रत्येक नियम को एक ओनर और एक समाप्ति लक्ष्य दें, मूल पेलोड और कॉन्ट्रैक्ट वर्ज़न बनाए रखें, और कतार की आयु और रिप्ले सफलता को मापें। एक दैनिक समीक्षा में विफलताओं को प्रोड्यूसर बग्स, कॉन्ट्रैक्ट दोष या अपेक्षित अपवादों के रूप में वर्गीकृत किया जाना चाहिए।
आप डेटा कॉन्ट्रैक्ट से कब बचेंगे?
एक मालिक वाली और बिना किसी डाउनस्ट्रीम वादे वाली निजी, अल्पकालिक टेबल के लिए, एक हल्का स्कीमा और टेस्ट्स सस्ते हो सकते हैं। पूर्ण कॉन्ट्रैक्ट तब पेश करें जब कई टीमें, रिप्ले, विनियमित फ़ील्ड्स या फ्रेशनेस प्रतिबद्धताएं अंतर्निहित मान्यताओं को जोखिम भरा बना दें।