प्रॉम्प्ट और दायरा
यह फ्रंटेंड सिस्टम-डिज़ाइन प्रश्न स्टेट मैनेजमेंट और डिस्ट्रीब्यूटेड अपडेट्स को जोड़ता है। उत्तर में केवल एक कैश जोड़ने के बजाय स्थानीय डेटा, एक म्यूटेशन कतार (mutation queue), सर्वर वर्ज़न और दृश्यमान रिकवरी स्टेट्स को आपस में जोड़ना चाहिए।
इंटरव्यूअर क्या जांच रहा है
- लोकल ड्राफ्ट, पेंडिंग म्यूटेशन और सर्वर-कन्फर्म्ड स्टेट को अलग करना।
- कॉन्फ़्लिक्ट रणनीति चुनना और उन फ़ील्ड्स की पहचान करना जिन्हें स्वचालित रूप से मर्ज (auto-merge) नहीं किया जा सकता है।
- पुनः प्रयासों (retries), डुप्लिकेट सबमिशन, बंद ब्राउज़र और कई टैब को संभालना।
- ऑफ़लाइन, सिंकिंग, कॉन्फ़्लिक्ट और विफलता की स्थितियों को समझने योग्य और पुनर्प्राप्ति योग्य (recoverable) बनाना।
स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न
पूछें कि क्या फ़ील्ड स्वतंत्र हैं और क्या कोई ऑडिटेड या उच्च जोखिम वाले फ़ील्ड हैं, जैसे कि पैसे से संबंधित। अटैचमेंट्स, सर्वर वर्ज़न या ऑपरेशन-लॉग सपोर्ट, क्या last-write-wins स्वीकार्य है, ब्राउज़र सपोर्ट और लोकल रिटेंशन आवश्यकताओं के बारे में स्पष्टीकरण मांगें।
30-सेकंड का उत्तर
मैं एक टिकाऊ (durable) स्थानीय स्टोर के रूप में IndexedDB का उपयोग करूँगा और प्रत्येक संपादन को clientMutationId और बेस सर्वर वर्ज़न के साथ रिकॉर्ड करूँगा। UI तुरंत स्थानीय परिणाम दिखाता है और इसे पेंडिंग के रूप में चिह्नित करता है। ऐप या एक सर्विस वर्कर ऑनलाइन होने पर कतार भेजता है। सर्वर वर्ज़न जांच और आइडमपोटेंसी (idempotency) का उपयोग करके सफलता, कॉन्फ़्लिक्ट या वैलिडेशन विफलता के साथ उत्तर देता है। सुरक्षित फ़ील्ड स्वचालित रूप से मर्ज हो सकते हैं; उच्च जोखिम वाले फ़ील्ड स्पष्ट विकल्प के लिए एक डिफ (diff) दिखाते हैं। प्रत्येक स्थिति पुनः प्रयास या अनडू (undo) का समर्थन करती है।
चरण-दर-चरण विस्तृत विश्लेषण
1. पहले स्टेट मॉडल को परिभाषित करें
प्रत्येक ड्राफ्ट में serverVersion, localVersion, syncState, और lastError होते हैं। प्रत्येक पेंडिंग म्यूटेशन clientMutationId, फ़ील्ड परिवर्तन, निर्माण समय और बेस वर्ज़न को संग्रहीत करता है। रीड्स स्थानीय स्टोरेज से आते हैं; नेटवर्क प्रतिक्रियाएं केवल वर्ज़न जांच के बाद ही मर्ज होती हैं, ताकि कोई पुरानी प्रतिक्रिया किसी नए संपादन को ओवरराइट न कर सके।
2. IndexedDB में पुनर्प्राप्ति योग्य तथ्यों को सुरक्षित रखें
IndexedDB बड़े संरचित ऑफ़लाइन डेटा के लिए उपयुक्त है, लेकिन डिज़ाइन में स्कीमा अपग्रेड, कोटा एरर और ब्राउज़र एविक्शन को संभालना आवश्यक है। ड्राफ्ट, म्यूटेशन रिकॉर्ड और कॉन्फ़्लिक्ट्स को अलग-अलग स्टोर करें, और एक ड्राफ्ट व उसके कतार रिकॉर्ड को एक ही ट्रांजेक्शन में कमिट करें। संवेदनशील फ़ील्ड को न्यूनतम रखें और लॉगआउट या समाप्ति पर उन्हें हटा दें।
3. सिंक ट्रिगर और आइडमपोटेंसी डिज़ाइन करें
ऑनलाइन होने पर तुरंत प्रयास करें और ऑफ़लाइन होने पर कतारबद्ध करें। जहाँ Background Sync समर्थित है, वहाँ सर्विस वर्कर के लिए एक विशिष्ट टैग पंजीकृत करें, लेकिन इस API को डिलीवरी की सार्वभौमिक गारंटी न मानें। प्रत्येक अनुरोध में clientMutationId और एक बेस वर्ज़न होता है; उसी आईडी को दोहराने पर म्यूटेशन को दोबारा लागू किए बिना वही परिणाम मिलता है।
4. फ़ील्ड जोखिम के अनुसार कॉन्फ़्लिक्ट नीति का मिलान करें
लेबल जैसे स्वतंत्र फ़ील्ड प्रति-फ़ील्ड वर्ज़न द्वारा मर्ज हो सकते हैं। पैसे, अनुमतियों और अनुपालन बयानों को चुपचाप last-write-wins का उपयोग नहीं करना चाहिए। किसी कॉन्फ़्लिक्ट पर, स्थानीय मान, सर्वर मान और संपादन समय को साथ-साथ दिखाएं; उपयोगकर्ता का चयन एक नया म्यूटेशन बनाता है। स्वचालित मर्ज को अपने इनपुट रिकॉर्ड करने चाहिए।
5. विफलताओं, पुनः प्रयासों और एकाधिक संदर्भों को संभालें
नेटवर्क विफलताओं के लिए कतार क्रम को सुरक्षित रखते हुए एक्सपोनेंशियल बैकऑफ़ (exponential backoff) का उपयोग करें। वैलिडेशन विफलताएं अनंत पुनः प्रयासों के बजाय संपादन योग्य त्रुटि स्थितियां बन जाती हैं। एकाधिक टैब BroadcastChannel या वर्ज़न जांच के माध्यम से समन्वय कर सकते हैं ताकि कोई पुराना म्यूटेशन दोबारा न भेजा जाए। एक टिकाऊ कतार अगले लॉन्च पर फिर से शुरू होती है, और UI पेंडिंग संख्या और अंतिम त्रुटि दिखाता है।
एक मजबूत उदाहरण उत्तर
मैं सबसे पहले फ़ील्ड जोखिम और ऑफ़लाइन सीमाओं को परिभाषित करूँगा। क्लाइंट ड्राफ्ट और एक म्यूटेशन कतार को IndexedDB में संग्रहीत करता है; प्रत्येक म्यूटेशन में एक clientMutationId और बेस serverVersion होता है, जबकि UI तुरंत स्थानीय परिणाम को पेंडिंग के रूप में दिखाता है। ऐप या सर्विस वर्कर पुनः कनेक्ट होने के बाद कतार भेजता है, और सर्वर वर्ज़न जांच और आइडमपोटेंसी का उपयोग करके सफलता, कॉन्फ़्लिक्ट या वैलिडेशन त्रुटि लौटाता है। स्वतंत्र फ़ील्ड स्वचालित रूप से मर्ज हो सकते हैं, लेकिन उच्च जोखिम वाले फ़ील्ड स्थानीय-बनाम-सर्वर डिफ दिखाते हैं और पुष्टि की मांग करते हैं। नेटवर्क विफलताओं में बैकऑफ़ होता है; व्यावसायिक विफलताएं संपादन योग्य हो जाती हैं। एकाधिक टैब वर्ज़न सूचनाओं का उपयोग करते हैं ताकि पुराना डेटा नए काम को ओवरराइट न कर सके। इंटरफ़ेस स्पष्ट रूप से ऑफ़लाइन, सिंकिंग, कॉन्फ़्लिक्ट, विफलता और सहेजी गई स्थितियों में अंतर करता है।
सामान्य गलतियाँ
- बिना म्यूटेशन कतार या बेस वर्ज़न के केवल नवीनतम फॉर्म को कैश करना।
- प्रत्येक फ़ील्ड पर टाइमस्टैम्प या last-write-wins लागू करना।
- हर ब्राउज़र में Background Sync को गारंटी मानना।
- बिना आइडमपोटेंसी कुंजी के पुनः प्रयास करना और डुप्लिकेट बनाना।
- केवल कंसोल में कॉन्फ़्लिक्ट लॉग करना और उपयोगकर्ता के लिए कोई रिकवरी पाथ न देना।
- स्कीमा अपग्रेड, कोटा, एकाधिक टैब और ब्राउज़र शटडाउन को अनदेखा करना।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि दो टैब एक ही समय में संपादन करें?
प्रत्येक टैब वर्ज़न परिवर्तनों की सदस्यता लेता है (subscribes) और उसका बेस पुराना होने पर मर्ज का अनुरोध करता है। भेजने से पहले वर्ज़न की दोबारा जांच करें; सर्वर अभी भी साझा म्यूटेशन आईडी को डुप्लिकेट-मुक्त करता है।
क्या ऑफ़लाइन डेटा लीक हो सकता है?
केवल आवश्यक फ़ील्ड स्थानीय रूप से संग्रहीत करें, संवेदनशील सामग्री को एन्क्रिप्ट करें, अवधारण (retention) समय कम करें, और लॉगआउट, साझा-डिवाइस उपयोग या नीति परिवर्तन पर इसे हटा दें।
यदि ब्राउज़र में Background Sync का अभाव हो तो क्या होगा?
फ़ॉलबैक ट्रिगर के रूप में ऐप लॉन्च, फ़ोकस, कनेक्टिविटी परिवर्तन और शॉर्ट पोलिंग का उपयोग करें, और उपयोगकर्ता को बताएं कि रिकॉर्ड पेंडिंग हैं। सिस्टम की शुद्धता इस API पर निर्भर नहीं होनी चाहिए।
स्वचालित मर्ज कब सुरक्षित होता है?
केवल तभी जब फ़ील्ड सेमेंटिक्स स्वतंत्र हों, वर्ज़न बेस ज्ञात हो, और अस्थायी विचलन स्वीकार्य हो। पैसे, अनुमतियों, इन्वेंट्री और ऑडिट फ़ील्ड के लिए स्पष्ट पुष्टि की आवश्यकता होनी चाहिए।