डेटा इंजीनियरिंग इंटरव्यू: आप एक फाइनेंशियल रिकॉन्सिलिएशन पाइपलाइन कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

एक ऑर्डर सिस्टम प्रति दिन 200 मिलियन लेनदेन उत्पन्न करता है। आंतरिक लेज़र ऑर्डर, भुगतान, रिफंड और शुल्क रिकॉर्ड करता है; पेमेंट प्रोवाइडर सेटलमेंट-बैच रिपोर्ट की आपूर्ति करता है; बैंक वास्तविक डिपॉज़िट की आपूर्ति करता है। एक T+1 पाइपलाइन डिज़ाइन करें जो पिछले दिन का कार्य 06:00 तक पूरा करे, छूटे हुए, डुप्लिकेट, राशि, शुल्क और मुद्रा के अंतरों की पहचान करे, और पुन: निष्पादन, मानवीय समीक्षा, रिफंड, कई मुद्राओं और ऑडिट ट्रेल्स का समर्थन करे।

मान लें कि आंतरिक लेज़र व्यवसाय का प्राथमिक सत्य स्रोत (source of truth) है, जबकि प्रोवाइडर और बैंक बाहरी सत्य स्रोत हैं। रिकॉन्सिलिएशन को लेज़र को ओवरराइट नहीं करना चाहिए या पंक्ति-स्तरीय अंतरों को केवल इसलिए नहीं छिपाना चाहिए क्योंकि कुल योग (totals) मेल खाते हैं। राशि, मुद्रा, सेटलमेंट तिथि, बैच और साक्ष्य ट्रेस करने योग्य रहने चाहिए।

इंटरव्यूअर क्या टेस्ट कर रहा है

पहला, क्या आप टूल चुनने से पहले फैक्ट्स, समय और इनवेरिएंट्स को परिभाषित कर सकते हैं? ट्रांजेक्शन तिथि, पोस्टिंग तिथि, सेटलमेंट तिथि और बैंक वैल्यू तिथि के बीच अंतर करें। पैसे को माइनर यूनिट्स में स्टोर करें, मुद्रा को अनिवार्य बनाएं और बार-बार होने वाले इम्पोर्ट को सुरक्षित बनाएं।

दूसरा, क्या आप मैचिंग को पूरे टेबल के जॉइन (full-table join) के बजाय एक लेयर्ड स्ट्रैटेजी बना सकते हैं? प्रोवाइडर ट्रांजेक्शन आईडी और बैच आईडी से शुरुआत करें, फिर ऑर्डर आईडी, राशि, मुद्रा और समय विंडो के सीमित संयोजनों का उपयोग करें। फ़ज़ी मिलान (fuzzy matches) को चुपचाप कन्फर्म करने के बजाय समीक्षा के लिए भेजा जाना चाहिए।

तीसरा, क्या आप विसंगति चक्र (discrepancy loop) को बंद कर सकते हैं? प्रत्येक विसंगति के लिए एक प्रकार, गंभीरता, साक्ष्य, ओनर, स्थिति, समय सीमा और सुधारात्मक कार्रवाई की आवश्यकता होती है। एक सुधार मूल विसंगति को बनाए रखते हुए एक नया रिकॉन्सिलिएशन वर्शन बनाता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

दायरे में क्या शामिल है? ऑथराइजेशन, कैप्चर, रिफंड, शुल्क, पेआउट, बैंक डिपॉज़िट, या ये सभी?
कौन सा टाइमज़ोन 06:00 को परिभाषित करता है? क्या सेटलमेंट और रिपोर्ट जनरेशन डेलाइट-सेविंग परिवर्तनों या छुट्टियों को पार कर सकते हैं?
क्या बाहरी रिपोर्ट इंक्रीमेंटली प्राप्त की जा सकती हैं? क्या फ़ाइल नाम, कर्सर, वर्शन और पुन: प्रयास करने योग्य डाउनलोड स्थिर हैं?
क्या पाइपलाइन लेज़र को स्वतः समायोजित (auto-adjust) कर सकती है? मान लें कि यह प्रस्तावित समायोजन बनाती है जिसे एक अधिकृत वर्कफ़्लो स्वीकृत करता है।
कौन सी FX नीति लागू होती है? ट्रांजेक्शन, सेटलमेंट और बैंक मुद्राओं को बनाए रखें, और दर स्रोत व सटीकता को परिभाषित करें।
समाधान SLA क्या है? उच्च-मूल्य, अनुपालन और ग्राहक-प्रभावित विसंगतियों के लिए एस्केलेशन परिभाषित करें।

30-सेकंड का उत्तर ढांचा

"मैं सबसे पहले तीनों स्रोतों को अपरिवर्तनीय (immutable) रॉ लेयर्स में सुरक्षित रखूंगा, फिर राशि, मुद्रा, समय और बाहरी आईडी को सामान्यीकृत (normalize) करूंगा। इम्पोर्ट रिपोर्ट वर्शन द्वारा इडेम्पोटेंट (idempotent) होते हैं; स्ट्रॉन्ग कीज़ पहले मेल खाती हैं, सीमित कंपोजिट कीज़ दूसरे स्थान पर, और अनिश्चित परिणाम समीक्षा कतार में जाते हैं। प्रत्येक बैच को पंक्ति-स्तर, समूहीकृत और कुल नियंत्रण प्राप्त होते हैं। विसंगतियां एक ऑडिट-योग्य स्टेट मशीन का उपयोग करती हैं और स्वीकृत समायोजन प्रविष्टियों के माध्यम से ठीक की जाती हैं। मैं समय सीमा से उल्टी दिशा में शेड्यूल करता हूं, फ़ाइल पूर्णता, लेटेंसी, मिलान दर, खुली राशि और पुन: निष्पादन की निगरानी करता हूं, और डुप्लिकेट फ़ाइलों, देर से आए रिफंड, आंशिक सेटलमेंट और FX परिवर्तनों का परीक्षण करता हूं।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: फैक्ट मॉडल और अकाउंटिंग विंडो को परिभाषित करें

अपरिवर्तनीय internal_entry, provider_entry, और bank_entry फैक्ट्स बनाएं। सोर्स-फ़ाइल हैश, पंक्ति संख्या, सोर्स, इनजेस्ट समय, रिपोर्ट वर्शन, व्यावसायिक तिथि और सेटलमेंट तिथि रखें। पैसे को पूर्णांक माइनर यूनिट्स के रूप में स्टोर करें, फ्लोटिंग पॉइंट के रूप में कभी नहीं, और मुद्रा की आवश्यकता रखें। ऑर्डर स्थिति को फंड स्थिति से अलग करें ताकि "भुगतान सफल" को "नकदी प्राप्त" न माना जाए।

चरण 2: सोर्स वर्शन द्वारा इडेम्पोटेंट रूप से इनजेस्ट करें

डाउनलोड को पहले ऑब्जेक्ट स्टोरेज में लिखें, फिर आकार, हैश, हस्ताक्षर और अपेक्षित पंक्ति गणना को सत्यापित करें। एक यूनिक की के रूप में source + report_id + version + row_number का उपयोग करें। एक डुप्लिकेट डाउनलोड एक इनजेशन रिकॉर्ड जोड़ता है लेकिन पैसे को दो बार पोस्ट नहीं कर सकता है। फ़ाइलों को ओवरराइट करने के बजाय पुराने प्रोवाइडर वर्शन को सुरक्षित रखें और प्रतिस्थापन संबंधों को रिकॉर्ड करें।

text

unique_key = source + report_id + version + row_number
if unique_key already exists: record_duplicate_download()
else: persist_raw_row()

चरण 3: एक पुन: निष्पादन योग्य (rerunnable) सामान्यीकरण लेयर बनाएं

वर्शन्ड डिक्शनरी के माध्यम से स्थिति, राशि के चिह्न, टाइमज़ोन, शुल्क प्रकार और बाहरी आईडी को मैप करें। प्रत्येक रूपांतरण एक normalization_run_id लिखता है; निश्चित इनपुट स्नैपशॉट और नियम वर्शन पुन: निष्पादन को नियतात्मक (deterministic) बनाते हैं। अज्ञात स्थितियां, नकारात्मक-राशि सिमेंटिक्स और मुद्राएं डिफ़ॉल्ट रूप से शून्य बनने के बजाय क्वारंटाइन में जाती हैं।

चरण 4: लेयर्ड मैचिंग का उपयोग करें

लेयर एक स्थिर प्रोवाइडर ट्रांजेक्शन, रिफंड और पेआउट आईडी का उपयोग करती है। लेयर दो समान मर्चेंट, मुद्रा और सेटलमेंट तिथि के भीतर ऑर्डर आईडी, राशि और एक अनुमत समय विंडो का उपयोग करती है। लेयर तीन केवल उम्मीदवारों को उत्पन्न करती है; विभिन्न मुद्राओं में समान राशि, कई बाहरी पंक्तियों में विभाजित एक आंतरिक आइटम, और सेटलमेंट्स में विभाजित एक बाहरी पंक्ति—इन सभी के लिए समीक्षा की आवश्यकता होती है।

चरण 5: तीन नियंत्रणों के साथ परिणाम सिद्ध करें

पंक्ति नियंत्रण सत्यापित करते हैं कि प्रत्येक फैक्ट का अधिकतम एक बार मिलान किया गया है। समूह नियंत्रण बैच, मुद्रा, सेटलमेंट तिथि और शुल्क प्रकार के अनुसार गणना और राशि की तुलना करते हैं। कुल नियंत्रण लेज़र, प्रोवाइडर रिपोर्ट और बैंक डिपॉज़िट में प्रारंभिक शेष (opening balance), इनफ्लो, आउटफ्लो, शुल्क, रिफंड और अंतिम शेष (closing balance) की तुलना करते हैं। जब वे असहमत हों तो प्रत्येक लेयर के लिए साक्ष्य सुरक्षित रखें; केवल एक "passed" फ़्लैग न दिखाएं।

चरण 6: विसंगतियों को एक स्टेट मशीन बनाएं

कम से कम छूटे हुए, डुप्लिकेट, राशि बेमेल, शुल्क बेमेल, मुद्रा या FX बेमेल, तिथि परिवर्तन और अज्ञात बाहरी स्थिति को वर्गीकृत करें। स्थितियां open, investigating, adjustment_pending, resolved, और accepted हो सकती हैं, जिसमें प्रत्येक ट्रांज़िशन पर कर्ता (actor), कारण, साक्ष्य और टाइमस्टैम्प शामिल हो। उच्च-मूल्य या अनुपालन विसंगतियों के लिए दो व्यक्तियों के अनुमोदन की आवश्यकता होती है; ऑटोमेशन केवल एक प्रस्ताव बना सकता है।

चरण 7: लेट डेटा, रिफंड और आंशिक सेटलमेंट को संभालें

जब किसी रिपोर्ट में देरी हो, तो केवल प्राप्त दायरे को बंद करें और बैच को अपूर्ण रखें। अस्थायी अनुपस्थिति को स्थायी रूप से छूटे हुए रिकॉर्ड में न बदलें। रिफंड और विवाद ट्रांजेक्शन तिथि के बाद आ सकते हैं, इसलिए घटना की तिथि और सेटलमेंट तिथि को अलग-अलग रिकॉर्ड करें। जब कोई लेनदेन कई पेआउट में विभाजित होता है तो वन-टू-मेनी संबंधों को बनाए रखें; एक समान शेष राशि अनमैच पंक्तियों को नहीं मिटाती है।

चरण 8: रिकवरी, पुन: निष्पादन और ऑडिट की योजना बनाएं

प्रत्येक रन के लिए इनपुट-फ़ाइल मैनिफ़ेस्ट, स्नैपशॉट समय, नियम वर्शन, मिलान परिणाम और आउटपुट विसंगतियों को सहेजें। अंतिम सफल चरण से पुनरारंभ करें, रन आईडी द्वारा पुन: निष्पादन आउटपुट को अलग करें, और यूनिक कीज़ द्वारा मर्ज करें। बैच, ट्रांजेक्शन या विसंगति द्वारा ट्रैसेबिलिटी के लिए रॉ फ़ाइलें, हैश, रिपोर्ट वर्शन, मानवीय निर्णय और समायोजन वाउचर बनाए रखें। Stripe भी शेष राशि, लेनदेन और पेआउट को अलग करता है और इसके बैलेंस लेनदेन को पुनः प्राप्त करने के लिए पेआउट आईडी का उपयोग करने की सिफारिश करता है, जिससे पता चलता है कि बाहरी सेटलमेंट बैच को केवल एक कुल योग में क्यों नहीं बदला जा सकता है।

ट्रेड-ऑफ़ और सीमाएं

ट्रेड-ऑफ़ 1: स्ट्रॉन्ग कीज़ या उच्चतर मिलान दर

स्ट्रॉन्ग-की ऑटोमेशन कम पंक्तियों का मिलान कर सकता है, लेकिन इसकी गलत-सकारात्मक (false-positive) लागत नियंत्रित होती है। व्यापक राशि और समय विंडो समान लेनदेन को मर्ज करने की संभावना को बढ़ाते हुए कवरेज में सुधार करते हैं। थ्रेशोल्ड, विंडो और फ़ॉलबैक को वर्शन करें; प्रत्येक गैर-नियतात्मक परिणाम को समीक्षा के लिए भेजें।

ट्रेड-ऑफ़ 2: दैनिक बैच या नियर रीयल-टाइम

T+1 बैच को पुन: प्रस्तुत करना और ऑडिट करना आसान होता है। नियर-रीयल-टाइम स्ट्रीम उच्च-मूल्य वाले मुद्दों को पहले सामने लाते हैं लेकिन उन्हें रिपोर्ट वर्शन, लेट डेटा और डुप्लिकेट इवेंट को संभालना होगा। बैच का उपयोग अकाउंटिंग निष्कर्ष के रूप में और स्ट्रीम का उपयोग एक अलर्टिंग लेयर के रूप में करें।

ट्रेड-ऑफ़ 3: स्वचालित समायोजन या मानवीय अनुमोदन

छोटे, स्पष्ट, प्रतिवर्ती (reversible) अंतर सीमित ऑटोमेशन का उपयोग कर सकते हैं। उच्च-मूल्य, मुद्रा, डुप्लिकेट-चार्ज और अनुपालन अंतरों के लिए मानवीय अनुमोदन की आवश्यकता होती है। दोनों रास्ते इतिहास को संपादित करने के बजाय मूल फैक्ट्स और समायोजन वाउचर को सुरक्षित रखते हैं।

विफलता अभ्यास (Failure Drills) और विकास योजना

अभ्यास 1: डुप्लिकेट फ़ाइलें और पंक्तियाँ

एक ही रिपोर्ट को तीन बार डिलीवर करें और सत्यापित करें कि फ़ाइल हैश, रिपोर्ट वर्शन और रो कीज़ डुप्लिकेट पोस्टिंग को रोकते हैं। एक लेनदेन को दो वर्शन में रखें और सत्यापित करें कि वर्शन संबंध और चयन नियम समझाने योग्य हैं।

अभ्यास 2: लेट रिफंड और आंशिक सेटलमेंट

सेटलमेंट के दो दिन बाद एक रिफंड डिलीवर करें और एक ऑर्डर को दो पेआउट में विभाजित करें। सत्यापित करें कि ट्रांजेक्शन, सेटलमेंट और डिपॉज़िट तिथियां अलग-अलग रहें, और एक नया रन ऐतिहासिक रनों को बदले बिना विसंगति को बंद कर दे।

अभ्यास 3: छूटा हुआ पृष्ठ और गलत FX दर

एक रिपोर्ट पृष्ठ को हटा दें या दर तालिका को बदल दें। पंक्ति गणना, हैश, कुल और मुद्रा नियंत्रणों को प्रकाशन को ब्लॉक करना चाहिए और बैच को रिकॉन्सिल्ड घोषित करने के बजाय पूरा होने की प्रतीक्षा के रूप में चिह्नित करना चाहिए।

सामान्य गलतियाँ और फॉलो-अप

गलती 1: केवल तीन योगों (totals) की तुलना करना

समान योग एक छूटी हुई और एक डुप्लिकेट पंक्ति को छिपा सकते हैं। पंक्ति मिलान, समूहीकृत नियंत्रण और कुल नियंत्रण बनाए रखें।

गलती 2: पैसे को फ्लोटिंग पॉइंट के रूप में स्टोर करना

फ्लोटिंग-पॉइंट त्रुटि गलत अंतर पैदा करती है। पूर्णांक माइनर यूनिट्स या फिक्स्ड दशमलव का उपयोग करें और हमेशा मुद्रा स्टोर करें।

गलती 3: पुरानी रिपोर्ट को ओवरराइट करना

ओवरराइट करने से ऑडिट और पुन: निष्पादन साक्ष्य नष्ट हो जाते हैं। रिपोर्ट को अपरिवर्तनीय रूप से स्टोर करें और सुधारों को वर्शन के रूप में व्यक्त करें।

गलती 4: फ़ज़ी मिलान को ऑटो-पोस्ट करना

समान राशि और निकटवर्ती समय पहचान साबित नहीं करते हैं। फ़ज़ी परिणामों को उम्मीदवार साक्ष्य के साथ समीक्षा में रखें।

गलती 5: भुगतान की सफलता को बैंक डिपॉज़िट मानना

भुगतान की स्थिति, प्रोवाइडर सेटलमेंट और बैंक डिपॉज़िट अलग-अलग फैक्ट्स हैं। उन्हें अलग से मॉडल करें और उन्हें बैच संबंधों के माध्यम से कनेक्ट करें।

गलती 6: रिपोर्ट जनरेशन और टाइमज़ोन की अनदेखी करना

रिपोर्ट सेटलमेंट के बाद उपलब्ध हो सकती हैं; टाइमज़ोन और छुट्टियां गलत छूटे हुए रिकॉर्ड बनाती हैं। स्रोत उपलब्धता प्रतिबद्धताओं से शेड्यूल करें और टाइमज़ोन को स्पष्ट रूप से स्टोर करें।

गलती 7: किसी समस्या को ठीक करने के लिए ऐतिहासिक लेज़र पंक्तियों को संपादित करना

सीधे संपादन मूल साक्ष्य को हटा देते हैं। विसंगति और नए रन से जुड़ी एक स्वीकृत समायोजन प्रविष्टि का उपयोग करें।