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

प्रॉम्प्ट और परिदृश्य

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

इंटरव्यूअर क्या जांच रहा है

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

शुरुआत में पूछने योग्य स्पष्टीकरण प्रश्न

1. कौन से फ़ील्ड स्वतंत्र रूप से मर्ज हो सकते हैं, और कौन से प्राइवेसी, पहचान या सिक्योरिटी से जुड़े हैं और उनके लिए सीरियलाइज़ेशन या मानवीय पुष्टि की आवश्यकता है?
2. क्या लक्ष्य स्ट्रॉन्ग, सेशन या इवेंचुअल कंसिस्टेंसी है, और यूज़र्स कितना रेप्लिकेशन डिले स्वीकार कर सकते हैं?
3. क्या एक यूज़र सक्रिय रूप से कई रीजन्स में राइट कर सकता है, या प्रति यूज़र या टेनेंट एक होम रीजन तय किया जा सकता है?
4. दोनों वर्ज़न्स को कितने समय तक उपलब्ध रहना चाहिए, और यूज़र्स, सपोर्ट तथा ऑडिटर्स को क्या दिखना चाहिए?

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

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

विस्तृत विश्लेषण

1. फ़ील्ड स्तर पर कंसिस्टेंसी का वर्गीकरण करें

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

2. सिंगल-होम, पार्टीशन-होम या मल्टी-राइटर रूटिंग चुनें

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

3. वर्ज़न्स, इवेंट्स और आइडेम्पोटेंसी डिज़ाइन करें

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

4. कॉन्फ़्लिक्ट डिटेक्शन और ऑटोमैटिक मर्ज को परिभाषित करें

दो वर्ज़न्स में तब कॉन्फ़्लिक्ट होता है जब कोई भी दूसरे को समाहित नहीं करता है। अलग-अलग (disjoint) फ़ील्ड्स मर्ज हो सकते हैं; एक ही फ़ील्ड किसी व्यावसायिक नियम का पालन करता है जैसे होम-रीजन प्राथमिकता, अंतिम राइटर या स्पष्ट समीक्षा। वॉल-क्लॉक समय को यूज़र का इरादा न मानें: क्लॉक स्क्यू (clock skew) के कारण पुरानी सामग्री जीत सकती है। प्रत्येक मर्ज के लिए नियम, स्रोत वर्ज़न्स और परिणाम रिकॉर्ड करें।

5. प्राइवेसी और सिक्योरिटी फ़ील्ड्स को सुरक्षित रखें

प्राइवेसी विजिबिलिटी, ईमेल, लॉगिन विधियों और MFA को सामान्य last-write-wins का उपयोग नहीं करना चाहिए। कंडीशनल राइट्स, होम-रीजन ऑथराइजेशन या मानवीय समीक्षा की आवश्यकता रखें, और कॉन्फ़्लिक्ट के दौरान विजिबिलिटी को सुरक्षित (conservative) रखें। रिकवरी APIs को ऑपरेटर को प्रमाणित करना चाहिए और कारण तथा अनुमति की जांच करनी चाहिए ताकि "कॉन्फ़्लिक्ट हल करना" प्रिविलेज एस्केलेशन का मार्ग न बन जाए।

6. रिकवरी और ऑब्जर्वेबिलिटी को प्राथमिकता दें

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

एक संपूर्ण और मजबूत उत्तर

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

सामान्य विफलता के प्रकार

• एक रिकॉर्ड-स्तरीय last-write-wins नियम लागू करना जो प्राइवेसी या सिक्योरिटी परिवर्तनों को ओवरराइट कर देता है।
• फ़ील्ड ग्रैन्युलैरिटी, स्टोरेज लागत और कॉन्फ़्लिक्ट के बाद यूज़र अनुभव को समझाए बिना केवल "वर्ज़न वेक्टर का उपयोग करें" कहना।
• डुप्लीकेट, आउट-ऑफ़-ऑर्डर, विलंबित रेप्लिकेशन और पुराने होम के पुनरुद्धार की अनदेखी करना, जिससे रिकवरी के दौरान दूसरा ओवरराइट हो जाए।
• ऑपरेशन IDs, ऑडिट इतिहास और यूज़र अनडू पाथ को छोड़ देना, जिससे मर्ज अस्पष्ट और ठीक न करने योग्य हो जाएं।
• लॉस्ट अपडेट्स, कॉन्फ़्लिक्ट रेट और मैनुअल लागत को मापे बिना केवल उपलब्धता और लेटेंसी पर चर्चा करना।

फॉलो-अप और विस्तार

फॉलो-अप 1: हर जगह last-write-wins का उपयोग क्यों नहीं किया जाता?

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

फॉलो-अप 2: क्या होम रीजन से उपलब्धता प्रभावित होती है?

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

फॉलो-अप 3: UI को कॉन्फ़्लिक्ट कैसे दिखाना चाहिए?

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

फॉलो-अप 4: जब रेप्लिकेशन में बहुत अधिक देरी हो तो रीड कैसे करें?

एक वर्ज़न या रीजन वॉटरमार्क लौटाएं ताकि क्लाइंट्स को ताजगी (freshness) का पता चले। महत्वपूर्ण प्रवाहों के लिए read-after-write को राइट रीजन पर रूट करें जबकि सामान्य रीड्स इवेंचुअल कंसिस्टेंसी स्वीकार करते हैं। जब डिले किसी सीमा से अधिक हो जाए तो अलर्ट करें, उच्च जोखिम वाले परिवर्तनों को सीमित करें, या यूज़र्स को होम रीजन पर रीडायरेक्ट करें।