सिस्टम डिज़ाइन इंटरव्यू: आप एक ऐसा A/B प्लेटफ़ॉर्म कैसे बनाएंगे जो एक्सपेरिमेंट-क्वालिटी विफलताओं का पता लगाता हो?

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

एक प्रोडक्ट ऑर्गनाइज़ेशन प्रतिदिन सैकड़ों A/B टेस्ट चलाता है। प्लेटफ़ॉर्म यूज़र्स को असाइन करता है, एक्सपोज़र रिकॉर्ड करता है, मेट्रिक्स की गणना करता है और क्वालिटी की निगरानी करता है। पिछले एक्सपेरिमेंट्स में असमान आवंटन, सैंपल-रेशियो मिसमैच (SRM), और बार-बार झांकने (repeated peeking) के कारण अमान्य निष्कर्षों जैसी समस्याएं देखी गईं। एक्सपेरिमेंट कॉन्फ़िगरेशन से लेकर निर्णय समीक्षा तक, डेटा डिले, स्टैटिस्टिक्स, अलर्ट्स और अनुमतियों सहित सिस्टम को डिज़ाइन करें।

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

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

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

1. क्या रैंडमाइज़ेशन यूज़र, डिवाइस, सेशन या रिक्वेस्ट के आधार पर है? क्या एक्सपेरिमेंट्स ऑर्थोगोनली चल सकते हैं?
2. प्रतिदिन कितने एक्सपेरिमेंट्स और यूज़र्स चलते हैं, और मेट्रिक लेटेंसी व रिटेंशन विंडोज़ क्या हैं?
3. प्राइमरी मेट्रिक्स, गार्डरेल्स और मिनिमम डिटेक्टेबल इफेक्ट्स (MDE) कैसे घोषित किए जाते हैं?
4. SRM या एक्सपोज़र डेटा गायब होने के बाद, क्या ट्रैफ़िक को पॉज़ किया जाना चाहिए, टेस्ट को अमान्य किया जाना चाहिए, या इसे दोबारा चलाया जाना चाहिए?
5. असाइनमेंट्स का निरीक्षण करने, स्टॉपिंग रूल्स बदलने और लॉन्च को मंज़ूरी देने का अधिकार किसके पास है?

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

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

चरण-दर-चरण विस्तृत उत्तर

1. एक्सपेरिमेंट और रैंडमाइज़ेशन की सीमाएं परिभाषित करें

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

2. असाइनमेंट को आउटकम इवेंट्स से अलग करें

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

{
  "experiment": "checkout-copy-v3",
  "experimentVersion": 7,
  "unitHash": "u_8f2c",
  "variant": "treatment",
  "event": "exposure",
  "eventTime": "2026-08-01T12:00:03Z",
  "schemaVersion": 2,
  "idempotencyKey": "u_8f2c:checkout-copy-v3:7:exposure"
}

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

3. रैंडमाइज़ेशन और SRM की निगरानी करें

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

4. निरंतर अवलोकन (continuous observation) और स्टॉपिंग को संभालें

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

5. स्ट्रीमिंग और बैच पाथ्स डिज़ाइन करें

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

6. निर्णयों को ऑडिट और रिलीज़ गेट्स से जोड़ें

एक्सपेरिमेंट की स्थितियों में draft, running, paused, invalid, concluded, और archived शामिल हैं। सीड, मेट्रिक या स्टॉपिंग रूल बदलने पर एक नया वर्ज़न बनता है और पुराना परिणाम फ़्रीज़ हो जाता है। डिसीज़न सर्विस डेटा वॉटरमार्क, मेथड, सैंपल साइज़, SRM स्टेट, गार्डरेल स्टेट और ऑडिट लिंक्स उत्सर्जित करती है। रिलीज़ केवल उसी concluded वर्ज़न को स्वीकार करती है जिसके क्वालिटी चेक्स पास हो चुके हों।

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

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

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

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

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

असाइन्ड और ट्रिगर्ड दोनों सैंपल्स की जांच क्यों करें?

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

आप म्यूचुअली एक्सक्लूसिव और ऑर्थोगोनल टेस्ट्स का समर्थन कैसे करते हैं?

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

एक एनीटाइम-वैलिड मेथड क्या हल करता है?

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

क्या SRM विफलता पर ऑटोमैटिक री-रन ट्रिगर होना चाहिए?

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