सिस्टम डिज़ाइन इंटरव्यू: स्नैपशॉट और कॉम्पैक्शन के साथ एक इवेंट लॉग डिज़ाइन करें

प्रॉम्प्ट और संदर्भ

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

यह सीनियर सिस्टम-डिज़ाइन, प्लेटफ़ॉर्म और डेटा-इन्फ्रास्ट्रक्चर इंटरव्यू के लिए उपयुक्त है। Martin Fowler का Event Sourcing लेख स्थिति परिवर्तनों को एक इवेंट अनुक्रम के रूप में रखने के मूल विचार को परिभाषित करता है। Apache Kafka का डिज़ाइन दस्तावेज़ पार्टिशन्ड लॉग, कंज्यूमर पोज़िशन्स और लॉग कॉम्पैक्शन की व्याख्या करता है जो प्रत्येक की (key) के लिए नवीनतम मान को बनाए रखता है। सार्वजनिक सिस्टम-डिज़ाइन प्रॉम्प्ट भी पार्टिशन्ड अपेंड-ओनली लॉग, रेप्लिकेशन, रिटेंशन, कॉम्पैक्शन और रिकवरी को मूल्यांकन क्षेत्रों के रूप में सूचीबद्ध करते हैं। ये स्रोत विषय की प्रासंगिकता का समर्थन करते हैं, लेकिन किसी निश्चित कंपनी प्रॉम्प्ट या इंटरव्यू आवृत्ति को स्थापित नहीं करते हैं। श्रेणी system-design है क्योंकि मुख्य कौशल एंड-टू-एंड कंसिस्टेंसी, रिकवरी सीमाएं और कैपेसिटी ट्रेड-ऑफ हैं।

इंटरव्यूअर्स क्या मूल्यांकन करते हैं

पहला, क्या उम्मीदवार इवेंट इतिहास को मटेरियलाइज़्ड वर्तमान स्थिति से अलग कर सकता है? एक स्नैपशॉट एक व्युत्पन्न (derived) त्वरण परत है; यह अपरिवर्तनीय (immutable) इवेंट्स की जगह नहीं ले सकता या किसी असंगत इवेंट सीमा को पार नहीं कर सकता।

दूसरा, क्या पार्टिशन की (key) क्रमबद्धता और स्केल दोनों को संतुष्ट करती है? टेनेंट या एग्रीगेट आईडी द्वारा पार्टिशनिंग एक एग्रीगेट के क्रम को सुरक्षित रखती है, लेकिन हॉट टेनेंट्स, क्रॉस-एग्रीगेट ट्रांज़ैक्शन और ग्लोबल क्रम के लिए स्पष्ट सीमाओं की आवश्यकता होती है।

तीसरा, क्या वे कॉम्पैक्शन सिमेंटिक्स को समझते हैं? की कॉम्पैक्शन प्रति की (key) नवीनतम रिकॉर्ड को बनाए रखता है और स्टेट-चेंज स्ट्रीम के लिए उपयुक्त है; यह एक इवेंट इतिहास नहीं है। विलोपन (deletes) के लिए टॉम्बस्टोन (tombstones) और एक रिटेंशन विंडो की आवश्यकता होती है, और कंज्यूमर यह नहीं मान सकते कि कॉम्पैक्शन से पहले और बाद में मनमाने ऑफसेट का एक ही अर्थ है।

अंत में, क्या वे संचालन को कवर करते हैं: स्नैपशॉट सत्यापन, इवेंट वर्ज़न, एटॉमिक चेकपॉइंट, रेप्लिकेशन पावती (acknowledgements), रिटेंशन लागत, कंज्यूमर लैग और स्कीमा संगतता अवलोकनीय (observable) होनी चाहिए।

पहले पूछे जाने वाले स्पष्टीकरण प्रश्न

• क्या इवेंट अपरिवर्तनीय ऑडिट तथ्य हैं या पुनर्निर्माण योग्य वर्तमान-स्थिति परिवर्तन हैं? ऑडिटिंग के लिए पूर्ण इतिहास की आवश्यकता होती है; स्टेट स्ट्रीम की कॉम्पैक्शन का उपयोग कर सकते हैं।
• क्रमबद्धता का दायरा क्या है? केवल समान एग्रीगेट, प्रति टेनेंट, या ग्लोबल? प्रत्येक गारंटी पार्टिशनिंग और थ्रूपुट को बदल देती है।
• क्या कंज्यूमर्स को किसी भी समय से रीप्ले करना चाहिए? यदि ऐसा है, तो केवल नवीनतम-की कॉम्पैक्शन अपर्याप्त है; एक संग्रह (archive) या अलग ऑडिट लॉग रखें।
• स्नैपशॉट कौन बनाता है और सत्यापित करता है? प्रोड्यूसर्स, कंज्यूमर्स और स्नैपशॉट वर्कर्स की अलग-अलग ज़िम्मेदारियाँ होती हैं; स्नैपशॉट को लॉग पोज़िशन और स्कीमा वर्ज़न से बाँधें।
• विलोपन (deletes) को कैसे दर्शाया जाता है? एक वर्ज़न्ड टॉम्बस्टोन या एक व्यावसायिक डिलीशन इवेंट के अलग-अलग कॉम्पैक्शन और अनुपालन अर्थ होते हैं।

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

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

गहन उत्तर

1. इवेंट फ़ील्ड और ऑर्डरिंग सीमाओं को परिभाषित करें

एक इवेंट में eventId, aggregateId, aggregateVersion, schemaVersion, पेलोड, निर्माण समय और स्रोत शामिल हैं। aggregateVersion एक एग्रीगेट के लिए मोनोटोनिक रूप से बढ़ता है। सशर्त अपेंड (conditional append) एक पुराने वर्ज़न को अस्वीकार करता है, जिससे दो समवर्ती राइटर्स को एक-दूसरे को चुपचाप ओवरराइट करने से रोका जाता है।

पार्टिशन की के रूप में एग्रीगेट आईडी का उपयोग करें ताकि एक एग्रीगेट एक क्रमबद्ध लॉग में प्रवेश करे। क्रॉस-पार्टिशन ग्लोबल क्रम का वादा न करें। यदि उत्पाद को क्रॉस-एग्रीगेट एटॉमिक तथ्य की आवश्यकता है, तो टाइमस्टैम्प द्वारा सॉर्ट करने के बजाय ट्रांज़ैक्शन परिणाम को एक एग्रीगेट इवेंट के रूप में एनकोड करें या ट्रांज़ैक्शनल आउटबॉक्स का उपयोग करें।

2. अपेंड, रेप्लिकेट और पावती (Acknowledge)

एक लीडर स्थानीय रूप से अपेंड करता है और पर्याप्त फॉलोअर्स को रेप्लिकेट करता है; कॉन्फ़िगर की गई कमिट स्थिति के बाद ही वह स्वीकृति की पावती देता है। इवेंट आईडी और प्रोड्यूसर अनुक्रम संख्याएं पुनः प्रयास (retry) डिडुप्लिकेशन का समर्थन करती हैं। डिस्क सेगमेंट आकार या समय के आधार पर रोल होते हैं, और इंडेक्स कंज्यूमर्स को ऑफसेट खोजने में मदद करते हैं।

पावती को स्पष्ट बनाएं: इसका मतलब है कि इवेंट एक पुनर्प्राप्ति योग्य कमिटेड लॉग में है, न कि यह कि प्रत्येक कंज्यूमर ने इसे प्रोसेस किया है या कोई मटेरियलाइज़्ड रीड मॉडल वर्तमान है। कंज्यूमर की विफलता किसी अपेंड किए गए इवेंट को रोल बैक नहीं करती है।

3. कंज्यूमर चेकपॉइंट और इडेम्पोटेंसी

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

जब कोई कंज्यूमर पिछड़ जाता है तो लॉग बनाए रखें; लैग को कम करने के लिए अनप्रोसेस्ड इवेंट्स को न छोड़ें। एक पुनर्निर्माण योग्य व्यू स्नैपशॉट ऑफसेट से शुरू हो सकता है। एक बाहरी साइड इफेक्ट जिसे पुनर्निर्मित नहीं किया जा सकता है, उसे ब्लाइंड रीप्ले के बजाय मुआवज़े (compensation) या समीक्षा की आवश्यकता होती है।

4. स्नैपशॉट प्रोटोकॉल

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

रिकवरी स्नैपशॉट को लोड करती है और snapshotOffset + 1 से रीप्ले करती है। यदि स्कीमा पुरानी है, तो स्थिति प्रकाशित करने से पहले एक वर्ज़न्ड माइग्रेशन चलाएं; माइग्रेशन विफलता को एक अमान्य स्थिति को ब्लॉक करना चाहिए। एक स्नैपशॉट एक कैश है: इसे हटाने से कोई लॉग क्षतिग्रस्त नहीं होता है और केवल रिकवरी समय बढ़ता है।

5. रिटेंशन, कॉम्पैक्शन और आर्काइव को अलग करें

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

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

6. स्कीमा, अव्यवस्था (Disorder), और पॉइज़न इवेंट्स

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

एक एग्रीगेट के लिए आउट-ऑफ-ऑर्डर इवेंट आमतौर पर एक प्रोड्यूसर या रेप्लिकेशन उल्लंघन का संकेत देते हैं। एक पुराने एग्रीगेट वर्ज़न को अस्वीकार करें और मरम्मत के लिए अंतराल बनाए रखें। क्रॉस-एग्रीगेट इवेंट्स के लिए व्यावसायिक समय या कारण-आईडी (causal-ID) मुआवज़ा नियम की आवश्यकता होती है; सर्वर आगमन समय कार्य-कारण (causality) का विकल्प नहीं है।

7. क्षमता, रिकवरी, और ऑब्ज़र्वेबिलिटी

प्रति सेकंड इवेंट्स, औसत और टेल पेलोड आकार, रेप्लिकेशन फ़ैक्टर, रिटेंशन विंडो, स्नैपशॉट आकार, कॉम्पैक्शन बचत और रीप्ले गति को मॉडल करें। छोटे स्नैपशॉट अंतराल रिकवरी में सुधार करते हैं लेकिन राइट एम्प्लीफिकेशन और स्टोरेज जोड़ते हैं। अधिक आक्रामक कॉम्पैक्शन स्थिति-पुनर्निर्माण लागत को कम करता है लेकिन ऑडिट और ऐतिहासिक प्रश्नों को कमजोर करता है।

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

उच्च-गुणवत्ता वाला नमूना उत्तर

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

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

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

सामान्य गलतियाँ

• स्नैपशॉट को इवेंट स्रोत मानना → किसी को हटाने से रिकवरी और ऑडिट साक्ष्य हट जाते हैं → स्नैपशॉट ऑफसेट-बाउंड व्युत्पन्न त्वरक हैं।
• कॉम्पैक्टेड लॉग को पूर्ण इतिहास मानना → मध्यवर्ती इवेंट और पॉइंट-इन-टाइम स्थिति समाप्त हो जाती है → ऑडिट इवेंट्स को आर्काइव करें और केवल स्टेट स्ट्रीम को कॉम्पैक्ट करें।
• सभी इवेंट्स को टाइमस्टैम्प द्वारा क्रमबद्ध करना → क्लॉक स्क्यू गलत क्रम बनाता है → एग्रीगेट वर्ज़न और पार्टिशन अनुबंध द्वारा क्रम परिभाषित करें।
• मनमाने साइड इफेक्ट्स के बाद ऑफसेट कमिट करना → डुप्लिकेट अपरिहार्य हैं लेकिन अनिर्दिष्ट हैं → हैंडलर्स को इडेम्पोटेंट बनाएं और मॉडल/चेकपॉइंट कपलिंग को परिभाषित करें।
• टॉम्बस्टोन को तुरंत हटाना → एक पिछड़ रहा कंज्यूमर एक की (key) को पुनर्जीवित कर सकता है → उन्हें कंज्यूमर अनुबंध विंडो के माध्यम से बनाए रखें।
• एक अज्ञात स्कीमा को छोड़ना और कमिट करना → लॉग और व्यू चुपचाप अलग हो जाते हैं → रोकें, पॉइज़न इवेंट को अलग करें, और साक्ष्य बनाए रखें।
• क्षमता मॉडलिंग छोड़ना → स्नैपशॉट, कॉम्पैक्शन, या रीप्ले आउटेज का अड़चन (bottleneck) बन जाते हैं → लैग, रिकवरी समय और राइट एम्प्लीफिकेशन की गणना करें।
• दावा करना कि एग्जैक्टली-वन्स प्रत्येक डुप्लिकेट को हल करता है → बाहरी साइड इफेक्ट अभी भी दोहरा सकते हैं → इडेम्पोटेंसी कीज़, ट्रांज़ैक्शन या मुआवज़े का उपयोग करें।

फॉलो-अप प्रश्न और उत्तर

केवल वर्तमान स्थिति को डेटाबेस में क्यों न संग्रहीत करें?

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

कॉम्पैक्शन के बाद एक नया कंज्यूमर शुरुआत से पुनर्निर्माण कैसे कर सकता है?

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

क्या होगा यदि स्नैपशॉट बनाए जाने के दौरान नए इवेंट आते हैं?

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

आप इवेंट स्कीमा को कैसे माइग्रेट करते हैं?

पहले अनुकूलता और वर्ज़न फ़ील्ड को परिभाषित करें, फिर कंज्यूमर्स को माइग्रेशन विंडो के दौरान पुराने और नए वर्ज़न पढ़ने दें। राइटर्स नए फ़ील्ड जोड़ते हैं और सभी कंज्यूमर्स के अपग्रेड होने के बाद ही पुराने फ़ील्ड को बंद करते हैं। ब्रेकिंग परिवर्तन एक नए इवेंट प्रकार या ऑफ़लाइन माइग्रेशन का उपयोग करते हैं, जिसे ऐतिहासिक इवेंट्स पर रीप्ले परीक्षणों द्वारा मान्य किया जाता है।