प्रतिनिधि इंटरव्यू विषय

प्रोडक्ट मैनेजर इंटरव्यू: यूजर एक्सपीरियंस के लिए स्ट्रांग, इवेन्चुअल या स्टेल-रीड कंसिस्टेंसी का चयन कैसे करें?

प्रोडक्टकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

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

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

एक मल्टी-रीजन SaaS ऑर्डर स्टेटस, अकाउंट बैलेंस, अनरीड नोटिफिकेशन और एनालिटिक्स दिखाता है। इंजीनियरिंग लेटेंसी और लागत कम करने के लिए हर जगह इवेन्चुअल कंसिस्टेंसी (eventual consistency) का प्रस्ताव देती है, जबकि फाइनेंस टीम बैलेंस के तुरंत सही होने की मांग करती है। यूजर जर्नी के अनुसार स्ट्रांग, इवेन्चुअल या बाउंडेड-स्टेलनेस (bounded-staleness) रीड्स चुनें, फिर प्रोडक्ट प्रॉमिस, SLO, डिग्रेडेड स्टेट्स और रिलीज गेट्स परिभाषित करें।

यह इस बात का परीक्षण करता है कि क्या कोई प्रोडक्ट मैनेजर डिस्ट्रीब्यूटेड-सिस्टम सिमेंटिक्स को मापने योग्य प्रोडक्ट पॉलिसी में बदल सकता है। AWS DynamoDB इवेन्चुअल और स्ट्रांग रीड्स प्रदान करता है, जबकि Google Cloud Spanner एक्सटर्नल कंसिस्टेंसी और नियंत्रित स्टेल रीड्स (stale reads) देता है; निर्णय किसी नारे पर नहीं, बल्कि रीड/राइट जर्नी पर निर्भर करता है।

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

  • क्या आप पूरे प्रोडक्ट को एक ही मोड में बांधने के बजाय यूजर एक्शन और जोखिम के आधार पर विभाजन करते हैं।
  • क्या आप "लेटेस्ट", रीड-आफ्टर-राइट (read-after-write), क्रॉस-रीजन और विफलता की दृश्यता को परिभाषित करते हैं।
  • क्या कंसिस्टेंसी के विकल्प लेटेंसी, कैपेसिटी, लागत, रेवेन्यू और ट्रस्ट मेट्रिक्स से जुड़ते हैं।
  • क्या आप डिग्रेडेड कॉपी, विवाद समाधान, प्रयोग और रिवर्सीबल रोलआउट डिजाइन करते हैं।

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

  1. कौन सा डेटा चार्ज, बैलेंस, इन्वेंटरी या अनुपालन (compliance) को प्रभावित करता है, और स्टेल विंडो से क्या नुकसान होगा?
  2. क्या यूजर ने अभी-अभी कुछ लिखा (राइट किया) है और वह अपने स्वयं के राइट को पढ़ने की उम्मीद करता है? कितना स्टेलनेस स्वीकार्य है?
  3. कौन से क्षेत्र (regions) डेटा को रेप्लिकेट करते हैं, और क्या विफलता मोड केवल-पठन (read-only), कतारबद्ध (queued) या छिपा हुआ हो सकता है?
  4. स्ट्रांग और इवेन्चुअल रीड्स के लिए वर्तमान लेटेंसी, कैपेसिटी और लागत की बेसलाइन क्या हैं?
  5. क्या प्रोडक्ट निश्चितता का दिखावा करने के बजाय प्रोसेसिंग, अंतिम अपडेट का समय, टकराव (conflict) या पुनः प्रयास (retry) दिखा सकता है?

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

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

चरण-दर-चरण उत्तर

1. डेटाबेस प्रोडक्ट्स से नहीं, एक्शन से शुरुआत करें

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

2. यूजर द्वारा सत्यापित करने योग्य वादा लिखें

इस शब्द को देखने योग्य भाषा में बदलें: "पेमेंट कन्फर्मेशन के बाद, बैलेंस पेज कन्फर्मेशन रिस्पॉन्स में नया बैलेंस दिखाता है," या "एनालिटिक्स 15 मिनट पीछे हो सकता है और अपने डेटा का समय प्रदर्शित करता है।" क्रॉस-रीजन विफलता के दौरान व्यवहार बताएं; "यह अंततः कन्वर्ज हो जाएगा" कोई तात्कालिक वादा नहीं है।

3. स्ट्रांग, इवेन्चुअल या बाउंडेड-स्टेलनेस रीड्स चुनें

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

4. रीड-आफ्टर-राइट और टकरावों को संभालें

राइट के बाद एक वर्जन, कन्फर्मेशन टोकन या अपडेट समय लौटाएं, और अगले रीड पर एक वर्जन स्थिति भेजें; आवश्यकता पड़ने पर राइट क्षेत्र में रूट करें। मल्टी-रीजन समवर्ती राइट्स (concurrent writes) के लिए मर्ज नियम, मानवीय समीक्षा या अस्वीकृति शर्तों की आवश्यकता होती है। जब तक नुकसान स्वीकार्य न हो, "लास्ट राइटर विन्स" (last writer wins) बैलेंस के लिए कोई प्रोडक्ट पॉलिसी नहीं है।

5. डिग्रेडेड एक्सपीरियंस और गार्डराइल डिजाइन करें

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

6. कैनरी, मापें और रोलबैक करें

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

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

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

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

सामान्य विफलता मोड

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

फॉलो-अप प्रश्न और संदर्भ उत्तर

इवेन्चुअल कंसिस्टेंसी कब स्वीकार्य है?

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

आप रीड-आफ्टर-राइट को प्रोडक्ट SLO के रूप में कैसे परिभाषित करते हैं?

राइट कन्फर्मेशन के बाद, घोषित समय और क्षेत्रीय दायरे में रीड्स को कम से कम उस वर्जन जितना नया डेटा लौटाना चाहिए। केवल औसत लेटेंसी ही नहीं, बल्कि विफलता दर और अधिकतम प्रतीक्षा समय को भी ट्रैक करें।

प्रत्येक पेज पर स्ट्रांग रीड्स का उपयोग क्यों नहीं किया जाता?

वे क्रॉस-रीजन लेटेंसी, कैपेसिटी और लागत बढ़ा सकते हैं, और विफलता के दौरान उपलब्धता को कम कर सकते हैं। स्ट्रांग सिमेंटिक्स को उन जर्नी के लिए सुरक्षित रखें जहां विश्वास और नुकसान संसाधनों को उचित ठहराते हैं।

मल्टी-रीजन इवेन्चुअल टकरावों को कैसे संभाला जाना चाहिए?

प्रति एंटिटी मर्ज करने योग्य फ़ील्ड, वर्जन स्थितियां और अनसुलझे मामलों के लिए एक मानव कतार (human queue) परिभाषित करें। गैर-मर्ज करने योग्य बैलेंस के लिए, चुपचाप अधिलेखित (overwrite) करने के बजाय अस्वीकार करें या लॉक करें।

आप यूजर्स को स्टेल डेटा के बारे में कैसे समझाते हैं?

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

आपको किसी भिन्न स्टोर या स्ट्रांग-कंसिस्टेंसी डेटाबेस पर कब जाना चाहिए?

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

सार्वजनिक स्रोत

संबंधित प्रश्न