प्रॉम्प्ट और दायरा
20,000 टेनेंट्स और प्रति घंटे 1 मिलियन ऑपरेशन्स मान लें, जिसमें 10x के छोटे बर्स्ट और 100 ms के भीतर p95 ऑथराइजेशन निर्णय शामिल हैं। ग्राहक ऑपरेशन्स चलाने से पहले क्रेडिट खरीदते हैं। प्रत्येक ऑपरेशन की लागत परिवर्तनीय होती है, अनुरोध समवर्ती (concurrently) आ सकते हैं, और यूसेज इवेंट्स की डिलीवरी कम से कम एक बार (at least once) होती है। डिज़ाइन को ऑडिट ट्रेल को संरक्षित करते हुए नेगेटिव बैलेंस और डबल चार्जिंग को रोकना चाहिए। यह खरीदे गए मूल्य का लेज़र है, कोई रेट लिमिटर या आवर्ती सब्सक्रिप्शन-बिलिंग सिस्टम नहीं।
इंटरव्यूअर क्या टेस्ट कर रहा है
- अपरिवर्तनीय (immutable) क्रेडिट गतिविधियों को तेज़ बैलेंस रीड मॉडल से अलग करना।
- authorize, capture, release, refund, और grant ऑपरेशनों को आइडम्पोटेंट बनाना।
- समवर्ती अनुरोधों, विलंबित इवेंट्स, पुनः प्रयासों, समाप्ति (expiry), और समाधान (reconciliation) को संभालना।
- कंसिस्टेंसी सीमाओं, हॉट टेनेंट्स, ऑब्जर्वेबिलिटी, और रिकवरी को समझाना।
पूछने के लिए स्पष्टीकरण संबंधी प्रश्न
पूछें कि क्या क्रेडिट समाप्त होते हैं, क्या कोई विफल ऑपरेशन पहले रिज़र्व और फिर रिलीज़ कर सकता है, रिफंड कैसे स्वीकृत होते हैं, क्या निष्पादन से पहले लागत ज्ञात होती है, और क्या एक टेनेंट कई क्षेत्रों में खर्च कर सकता है। आवश्यक निर्णय विलंबता (latency) की पुष्टि करें और क्या अस्थायी ओवर-ऑथराइजेशन की अनुमति है।
30-सेकंड का उत्तर
मैं ग्रांट्स, रिज़र्वेशन्स, कैप्चर्स, रिलीज़, रिफंड और समाप्ति का एक अपेंड-ओनली, अपरिवर्तनीय लेज़र उपयोग करूँगा। एक ट्रांजैक्शनल बैलेंस प्रोजेक्शन तेज़ रीड्स का समर्थन करता है, जबकि एक आइडम्पोटेंसी की प्रत्येक म्यूटेशन को दोहराने योग्य बनाती है। ऑथराइजेशन परमाणु रूप से (atomically) उपलब्ध क्रेडिट की जांच करता है और समाप्ति समय के साथ एक रिज़र्वेशन बनाता है; सफल कार्य इसे कैप्चर करता है, विफलताएं इसे रिलीज़ करती हैं, और एक रिक्लेमर छोड़े गए रिज़र्वेशन्स को संभालता है। एक आउटबॉक्स, रीप्ले करने योग्य इवेंट्स, और समाधान (reconciliation) प्रोजेक्शन की तुलना लेज़र से करते हैं और ऑडिट योग्य क्षतिपूर्ति प्रविष्टियों (compensating entries) के साथ विचलन को ठीक करते हैं।
चरण-दर-चरण गहन विश्लेषण
1. क्रेडिट स्थिति को मॉडल करें
एक टेनेंट/अकाउंट की, पूर्णांक क्रेडिट इकाइयाँ, एक लेज़र अनुक्रम, और स्वीकृत, आरक्षित, कैप्चर किए गए, रिलीज़ किए गए, रिफंड किए गए और समाप्त योग वाले प्रोजेक्शन को बनाए रखें। प्रत्येक म्यूटेशन को operationid, idempotencykey, कारण, कर्ता (actor), और टाइमस्टैम्प के साथ स्टोर करें। पुरानी प्रविष्टि को कभी संपादित न करें; सुधार के लिए एक क्षतिपूर्ति प्रविष्टि जोड़ी जाती है।
2. बिना डबल स्पेंडिंग के अधिकृत करें
टेनेंट की हॉट की के लिए एक ट्रांजैक्शन या लीनियरिज़ेबल कंडीशनल अपडेट का उपयोग करें: रिज़र्वेशन केवल तभी बनाएं जब उपलब्ध क्रेडिट कम से कम अनुरोधित लागत के बराबर हों। एक दोहराई गई आइडम्पोटेंसी की मूल निर्णय लौटाती है; भिन्न मापदंडों के साथ पुनः उपयोग की गई कुंजी को अस्वीकार कर दिया जाता है। रिज़र्वेशन समाप्ति और स्थिति परिवर्तनों को सशर्त रखें ताकि कैप्चर और रिलीज़ दोनों एक साथ सफल न हो सकें।
3. निष्पादन और इवेंट्स को कनेक्ट करें
व्यावसायिक अनुरोध में रिज़र्वेशन पहचानकर्ता होता है। कैप्चर पुष्ट सफलता का अनुसरण करता है; रिलीज़ विफल या रद्द किए गए ऑपरेशन का अनुसरण करता है। यूसेज इवेंट्स डुप्लिकेट या विलंबित हो सकते हैं, इसलिए उपभोक्ता आँख मूंदकर काउंटर घटाने के बजाय event_id द्वारा डिडुप्लिकेट करते हैं और अज्ञात रिज़र्वेशन्स का समाधान करते हैं। एक आउटबॉक्स ट्रांजैक्शन के बाद कमिट किए गए लेज़र परिवर्तनों को प्रकाशित करता है।
4. स्केल करें, विकल्प और पुनर्प्राप्ति
टेनेंट द्वारा पार्टीशन करें, एक टेनेंट को होम राइटर पर रूट करें, और एडमिशन कंट्रोल या सीरियलाइज़्ड कमांड स्ट्रीम के साथ असाधारण रूप से हॉट टेनेंट्स को अलग करें। जब प्रत्येक टेनेंट की राइट दर मध्यम हो, तो रिलेशनल ट्रांजैक्शन अधिक सरल और उपयुक्त होता है; अत्यधिक हॉट टेनेंट्स के लिए इवेंट-सोर्स्ड कमांड स्ट्रीम बेहतर होती है जब क्वेरी सरलता की तुलना में रीप्ले और ऑर्डरिंग अधिक मायने रखते हैं। रीड्स केवल तभी रेप्लिकस का उपयोग कर सकते हैं जब उनका पुरानापन (staleness) दिखाया गया हो। एक स्वीपर छोड़े गए रिज़र्वेशन्स को समाप्त करता है, और रीप्ले लेज़र से प्रोजेक्शन का पुनर्निर्माण करता है। अलर्ट नकारात्मक उपलब्धता, समाप्ति-के-बाद-कैप्चर, रीप्ले अंतराल और समाधान अंतर को कवर करते हैं।
एक मजबूत नमूना उत्तर
मैं समाप्ति, रिफंड प्राधिकरण, बहु-क्षेत्रीय खर्च, और निष्पादन से पहले लागत ज्ञात है या नहीं, इसे स्पष्ट करूँगा। सत्य का स्रोत (source of truth) प्रति-टेनेंट एक अपरिवर्तनीय लेज़र है; बैलेंस टेबल एक पुनर्निर्माण योग्य प्रोजेक्शन है। authorize एक आइडम्पोटेंसी की और समाप्ति के तहत लागत को परमाणु रूप से रिज़र्व करता है, capture सफलता के बाद उस रिज़र्वेशन को परिवर्तित करता है, और release या समाप्ति इसे वापस लौटाती है। डुप्लिकेट या विलंबित इवेंट्स को डिडुप्लिकेट और सुलझाया जाता है। टेनेंट-संबद्ध राइट्स क्रॉस-रीजन डबल स्पेंडिंग से बचाते हैं; यदि किसी क्षेत्र को स्वतंत्र रूप से काम करना चाहिए, तो उसे एक सीमित आवंटन प्राप्त होता है जिसके ऋण का स्पष्ट रूप से समाधान किया जाता है। प्रत्येक सुधार एक अपेंड-ओनली क्षतिपूर्ति प्रविष्टि है।
सामान्य गलतियाँ
- केवल म्यूटेबल काउंटर → पुनः प्रयासों और रिफंड का ऑडिट नहीं किया जा सकता → ऑपरेशन पहचान के साथ एक अपरिवर्तनीय प्रविष्टि जोड़ें।
- अनुरोध प्राप्त होने पर चार्ज करना → विफल कार्य फिर भी क्रेडिट खर्च करता है → पहले रिज़र्व करें और सफलता के बाद ही कैप्चर करें।
- पुनः प्रयास को नई खपत के रूप में मानना → एक ही ऑपरेशन के लिए दो बार चार्ज किया जाता है → समान आइडम्पोटेंसी की का पुनः उपयोग करें।
- रिज़र्वेशन कभी पुनः प्राप्त नहीं किया गया → क्रैश हुए वर्कर्स क्रेडिट को हमेशा के लिए लॉक कर देते हैं → समाप्ति और एक सशर्त स्वीपर जोड़ें।
- अंततः सुसंगत क्रॉस-रीजन रीड → दो राइटर्स अधिक खर्च कर सकते हैं → एक राइटर या स्पष्ट क्षेत्रीय बजट का उपयोग करें।
- इतिहास को ठीक करने के लिए पुरानी पंक्तियों को संपादित करना → ऑडिट ट्रेल अविश्वसनीय हो जाता है → एक क्षतिपूर्ति प्रविष्टि जोड़ें।
फॉलो-अप प्रश्न और प्रतिक्रियाएं
ऑथराइजेशन के बाद क्लाइंट टाइम आउट हो गया। क्या होता है?
रिज़र्वेशन को क्वेरी करें या उसी आइडम्पोटेंसी की के साथ अगले ट्रांजिशन का पुनः प्रयास करें। जब तक मूल रिज़र्वेशन कैप्चर, रिलीज़ या समाप्त नहीं हो जाता, तब तक फिर से अधिकृत न करें।
महीना बंद होने के बाद आप रिफंड की प्रक्रिया कैसे करते हैं?
मूल कैप्चर और अनुमोदन रिकॉर्ड का संदर्भ देते हुए एक रिफंड प्रविष्टि जोड़ें। प्रोजेक्शन उपलब्ध क्रेडिट को बढ़ाता है, जबकि लेज़र दोनों इवेंट्स और उनके क्रम को सुरक्षित रखता है।
क्या दो क्षेत्र एक ही खाते को समवर्ती रूप से खर्च कर सकते हैं?
सख्त नो-डबल-स्पेंड सेमेंटिक्स के लिए सिंगल राइटर या टेनेंट होम रीजन को प्राथमिकता दें। यदि सीमित स्थानीय खर्च की आवश्यकता है, तो स्पष्ट क्षेत्रीय बजट आवंटित करें और ऋण का समाधान करें; अधिकतम अस्थायी ओवरएज का उल्लेख करें।
आप कैसे साबित करते हैं कि बैलेंस सही है?
समय-समय पर लेज़र को रीप्ले करें, व्युत्पन्न उपलब्ध राशि की तुलना प्रोजेक्शन से करें, और कैप्चर्स की तुलना व्यावसायिक-संचालन परिणामों से करें। प्रत्येक सुधार के लिए एक आइडम्पोटेंट क्षतिपूर्ति प्रविष्टि और एक ऑडिट रिकॉर्ड जारी करें।