प्रांप्ट और पृष्ठभूमि
एक ही यूसेज इवेंट ऑपरेशनल सीमाओं और वित्तीय रिपोर्टिंग दोनों को पूरा करता है। इवेंट्स देर से आ सकते हैं, डुप्लिकेट हो सकते हैं, या सुधारे जा सकते हैं, और एक शोर करने वाले (noisy) टेनेंट के कारण दूसरों में देरी नहीं होनी चाहिए या उसे किसी अन्य टेनेंट का डेटा नहीं देखना चाहिए।
इंटरव्यूअर क्या जांचता है
- इम्यूटेबल फैक्ट्स को म्यूटेबल प्रोजेक्शन से अलग करना।
- Idempotency, इवेंट-टाइम विंडोज़, सुधार और इनवॉइस की अंतिमता (finality) को परिभाषित करना।
- टेनेंट आइसोलेशन, बैकप्रेशर और मिलान (reconciliation) साक्ष्य डिज़ाइन करना।
उत्तर देने से पहले स्पष्टीकरण प्रश्न
- इवेंट रेट, डाइमेंशन, रिटेंशन और इनवॉइस फ़ाइनलाइज़ेशन की समय सीमा क्या है?
- क्या उपयोग को रिक्वेस्ट स्वीकृति, पूर्णता, या सफल व्यावसायिक प्रभाव पर मापा जाता है?
- क्या प्रोड्यूसर इवेंट ID दोबारा भेज सकते हैं, और सुधारों या रिफंड को कैसे दर्शाया जाता है?
- किन कोटा निर्णयों के लिए सेकंड-स्तरीय ताज़गी (freshness) की आवश्यकता होती है, और किन रिपोर्टों में देरी हो सकती है?
30-सेकंड उत्तर ढांचा
मैं एक स्थिर इवेंट ID, इवेंट टाइम, यूनिट, सोर्स और स्कीमा संस्करण के साथ टेनेंट-स्कोप्ड इम्यूटेबल यूसेज फैक्ट कैप्चर करूँगा। एक अपेंड-ओनली लॉग अलग-अलग कोटा और बिलिंग प्रोजेक्शन को फ़ीड करता है। डीडुप्लिकेशन टेनेंट और इवेंट ID द्वारा की जाती है; सुधार नए फैक्ट्स होते हैं, न कि ओवरराइट। कोटा रीड्स एक तेज़ बाउंडेड प्रोजेक्शन का उपयोग करते हैं, जबकि इनवॉइस केवल वॉटरमार्क और रीकॉन्सिलेशन पास के बाद ही बंद होते हैं। प्रत्येक एग्रीगेट सोर्स फैक्ट्स तक ट्रेसेबल रहता है।
चरण-दर-चरण गहन विश्लेषण
1. फैक्ट को कैप्चर करना
प्रोड्यूसर को प्रमाणित करें, टेनेंट स्कोप और यूनिट्स को मान्य करें, और पावती (acknowledgment) देने से पहले रॉ इवेंट को सुरक्षित रखें। प्रोड्यूसर इवेंट ID, सोर्स, इवेंट टाइम और माप संस्करण की मांग करें। गलत स्वरूपित या क्रॉस-टेनेंट राइट्स को अस्वीकार करें और ऑडिट के लिए एक डाइजेस्ट बनाए रखें।
2. राइट्स को Idempotent बनाना
(tenant, source, event_id) पर विशिष्टता प्रतिबंध (uniqueness constraint) लागू करें। समान डाइजेस्ट वाला डुप्लिकेट मौजूदा परिणाम लौटाता है; एक अलग डाइजेस्ट को कॉन्फ्लिक्ट के रूप में क्वारंटाइन किया जाता है। इनवॉइस रो को idempotency स्टोर के रूप में उपयोग न करें क्योंकि ऑपरेशनल पुनरुपयोग (retries) इनवॉइसिंग से पहले होते हैं।
3. कोटा और बिलिंग को अलग-अलग प्रोजेक्ट करना
कोटा प्रोजेक्शन छोटी विंडोज़, वर्तमान काउंटर्स और ताज़गी अज्ञात होने पर फेल-क्लोज्ड पॉलिसी रखता है। बिलिंग अनुबंध यूनिट और मूल्य संस्करण द्वारा एग्रीगेट करती है, जो इवेंट-टाइम बकेट्स और सुधार लिंक को संरक्षित करती है। कोई भी प्रोजेक्शन इम्यूटेबल फैक्ट लॉग को संपादित नहीं करता है।
4. लेट डेटा संभालना और इनवॉइस बंद करना
देखे गए इवेंट टाइम और एक सहमत विलंबता सीमा के आधार पर वॉटरमार्क का उपयोग करें। वॉटरमार्क के बाद के इवेंट एडजस्टमेंट लेज़र और अगले बिलिंग चक्र या क्रेडिट वर्कफ़्लो में प्रवेश करते हैं। फ़ाइनलाइज़ेशन से पहले, प्रोजेक्शन के विरुद्ध लॉग से काउंट्स और सम्स का मिलान करें और कैलकुलेशन वर्ज़न रिकॉर्ड करें।
5. सुरक्षित रूप से संचालन करना
टेनेंट या फेयर-शेयर कुंजी द्वारा क्यू और स्टोरेज को पार्टिशन करें, कोटा और बैकप्रेशर लागू करें, और डेड लेटर्स को अलग करें। इनजेशन लैग, डुप्लिकेट और कॉन्फ्लिक्ट दरें, वॉटरमार्क आयु, प्रोजेक्शन ड्रिफ्ट, सुधार की मात्रा और इनवॉइस-क्लोज़ लेटेंसी की निगरानी करें। डेटा को एन्क्रिप्ट करें, निर्यात प्रतिबंधित करें, और प्रत्येक सुधार को ऑडिट योग्य बनाएं।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं पावती देने से पहले इवेंट ID, सोर्स, इवेंट टाइम, यूनिट, स्कीमा और मूल्य संस्करण के साथ एक इम्यूटेबल, टेनेंट-स्कोप्ड यूसेज फैक्ट स्टोर करूँगा। एक अपेंड-ओनली लॉग स्वतंत्र कोटा और बिलिंग प्रोजेक्शन को फ़ीड करता है। समान-ID और समान-डाइजेस्ट वाले रिट्राइज़ idempotent होते हैं; बदले हुए डाइजेस्ट को क्वारंटाइन किया जाता है। कोटा एक तेज़ बाउंडेड प्रोजेक्शन का उपयोग करता है, जबकि इनवॉइस केवल लेटेंसी वॉटरमार्क और सोर्स फैक्ट्स के विरुद्ध मिलान के बाद ही बंद होते हैं। लेट इवेंट्स एडजस्टमेंट रिकॉर्ड बन जाते हैं, और टेनेंट पार्टिशनिंग, बैकप्रेशर, एन्क्रिप्शन और ड्रिफ्ट मेट्रिक्स शुद्धता और निष्पक्षता की रक्षा करते हैं।”
सामान्य गलतियाँ
- प्रत्येक इवेंट पर एग्रीगेट को ओवरराइट करना → लेट डेटा और सुधार अदृश्य हो जाते हैं → इम्यूटेबल फैक्ट्स और प्रोजेक्शन बनाए रखें।
- वॉल-क्लॉक आगमन को यूसेज टाइम के रूप में उपयोग करना → विलंबित इवेंट्स गलत इनवॉइस में चले जाते हैं → इवेंट टाइम और वॉटरमार्क द्वारा बकेट करें।
- एक ग्लोबल क्यू शेयर करना → एक शोर करने वाला टेनेंट हेड-ऑफ़-लाइन ब्लॉकिंग बनाता है → पार्टिशन करें या फेयर शेयर लागू करें।
- बिना मिलान के फ़ाइनलाइज़ करना → प्रोजेक्शन ड्रिफ्ट एक बिलिंग विवाद बन जाता है → प्रोजेक्शन की सोर्स फैक्ट्स से तुलना करें और कैलकुलेशन को वर्ज़न करें।
फॉलो-अप प्रश्न और उत्तर
आप रिफंड या सुधार का समर्थन कैसे करते हैं?
मूल इवेंट और अनुबंध संस्करण से जुड़ा एक कंपेंसेटिंग फैक्ट जोड़ें। प्रभावित प्रोजेक्शन की पुनर्गणना करें या एक एडजस्टमेंट लेज़र प्रविष्टि बनाएं; मूल साक्ष्य को कभी भी म्यूटेट न करें।
यदि कोटा और बिलिंग अस्थायी रूप से असहमत हों तो क्या होगा?
अलग-अलग ताज़गी और अंतिमता गारंटी घोषित करें। कोटा एक बाउंडेड विंडो के भीतर अनुमानित हो सकता है, जबकि बिलिंग तब तक अनंतिम रहती है जब तक वॉटरमार्क और मिलान जांच पास न हो जाए; ऑपरेटरों और ग्राहकों के सामने स्थिति स्पष्ट रखें।
आप किसी टेनेंट को दूसरे टेनेंट का उपयोग डेटा पढ़ने से कैसे रोकते हैं?
राइट पाथ, स्टोरेज पार्टिशन, प्रोजेक्शन क्वेरी, एक्सपोर्ट और सपोर्ट टूलिंग में टेनेंट स्कोप लागू करें। प्रत्येक सीमा पर ऑथराइजेशन का परीक्षण करें और संवेदनशील इवेंट पेलोड को शामिल किए बिना एक्सेस लॉग करें।