एक मल्टी-चैनल नोटिफिकेशन सिस्टम डिज़ाइन करें

समस्या और लागू होने वाले परिदृश्य

प्रमाणीकरण (authentication), ऑर्डरिंग, सोशल और मार्केटिंग सेवाओं द्वारा उपयोग किए जाने वाले एक साझा नोटिफिकेशन प्लेटफ़ॉर्म को डिज़ाइन करें। यह मोबाइल पुश, SMS, ईमेल और इन-ऐप संदेशों का समर्थन करता है। ट्रांज़ैक्शनल संदेशों में OTP और भुगतान परिणाम शामिल हैं; बल्क संदेशों में इवेंट रिमाइंडर और मार्केटिंग प्रचार शामिल हैं। कॉलर तुरंत भेज सकता है या किसी नोटिफिकेशन को शेड्यूल कर सकता है। उपयोगकर्ता चैनल और नोटिफिकेशन प्रकार के अनुसार ऑप्ट-आउट कर सकते हैं, और मार्केटिंग संदेशों को प्रत्येक उपयोगकर्ता के टाइम ज़ोन में शांत घंटों (quiet hours) का सम्मान करना चाहिए।

इन इंटरव्यू मान्यताओं का उपयोग करें:

• सिस्टम प्रति दिन एक अरब चैनल-डिलीवरी कार्य (tasks) बनाता है। SMS और ईमेल दोनों द्वारा भेजे गए एक व्यावसायिक नोटिफिकेशन को दो कार्य गिना जाता है।
• औसत थ्रूपुट 1,000,000,000 / 86,400 ≈ 11,600 कार्य प्रति सेकंड है। अभियान के चरम (peak) का अनुमान औसत से 20 गुना, या लगभग 232,000 कार्य प्रति सेकंड लगाएं।
• ड्यूरेबल API स्वीकृति के लिए उपलब्धता लक्ष्य 99.99% है, जिसमें p99 स्वीकृति विलंबता 200 मिलीसेकंड से कम है।
• OTP के लिए, स्वीकृति से लेकर चैनल प्रदाता को सबमिशन तक का p99 समय दो सेकंड से कम है। मार्केटिंग कार्य को 15 मिनट में सुचारू (smooth) किया जा सकता है। दोनों में से कोई भी लक्ष्य यह वादा नहीं करता है कि कोई डिवाइस वास्तव में संदेश कब प्रदर्शित करता है।
• यदि एक डिलीवरी कार्य के लिए ड्यूरेबल एनवलप का औसत 1 KB है, तो इंडेक्स, रेप्लिकस, प्राप्तियों और कम्प्रेशन से पहले लॉजिकल राइट्स लगभग 1 TB प्रति दिन और 30 दिनों में 30 TB होते हैं।

ये मान विभाजन (partitioning), बैकलॉग और पृथक्करण (isolation) के निर्णयों को संचालित करते हैं; वे प्रदाता प्रदर्शन के दावे नहीं हैं। टेम्प्लेट संलेखन, ऑडियंस-चयन एल्गोरिदम, बिलिंग और A/B परीक्षण दायरे से बाहर हैं। यह प्रश्न वरिष्ठ बैकएंड, प्लेटफ़ॉर्म और सिस्टम डिज़ाइन भूमिकाओं को लक्षित करता है। इसकी मुख्य चुनौती विभिन्न सिमेंटिक्स वाले बाहरी चैनलों में प्राथमिकता, पुनर्प्राप्ति योग्यता और सच्ची अवलोकन क्षमता (truthful observability) को बनाए रखना है।

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

पहला संकेत यह है कि क्या उम्मीदवार "सफलतापूर्वक भेजा गया" को परिभाषित करता है। एक API 202 का अर्थ है कि प्लेटफ़ॉर्म ने कार्य को ड्यूरेबल रूप से स्वीकार कर लिया है। एक सफल प्रदाता प्रतिक्रिया का आमतौर पर अर्थ होता है कि प्रदाता ने अनुरोध स्वीकार कर लिया है। डिवाइस प्राप्ति, ऑपरेटिंग-सिस्टम डिस्प्ले और उपयोगकर्ता द्वारा खोलना बाद की स्थितियाँ हैं। Firebase के Sends मेट्रिक का अर्थ यह हो सकता है कि संदेश को कतारबद्ध किया गया था या APNs को पास किया गया था, जबकि एक सफल APNs प्रतिक्रिया अनुरोध का वर्णन करती है। इन सभी को delivered में समेटना ऑपरेशनल मेट्रिक्स और घटना प्रतिक्रिया (incident response) दोनों को दूषित करता है।

दूसरा संकेत यह है कि क्या प्राथमिकता को संसाधन पृथक्करण द्वारा समर्थित किया गया है। प्राथमिकता फ़ील्ड वाली एक साझा कतार के डिस्क, उपभोक्ता कनेक्शन और प्रदाता कोटा को अभी भी 50-मिलियन-उपयोगकर्ता अभियान द्वारा घेरा जा सकता है। एक मजबूत डिज़ाइन ट्रांज़ैक्शनल और बल्क कतारों, उपभोक्ताओं और संरक्षित चैनल बजट को अलग करता है, जबकि बल्क ट्रैफ़िक को निष्क्रिय क्षमता (idle capacity) उधार लेने की अनुमति देता है। OTP ट्रैफ़िक को भी अपनी सीमा की आवश्यकता होती है; एक "क्रिटिकल" लेबल को हर सुरक्षा को बायपास नहीं करना चाहिए।

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

चौथा संकेत एक बंद विफलता लूप (closed failure loop) है। स्थायी विफलताएं पुनः प्रयास करना बंद कर देती हैं और उचित होने पर अमान्य एंडपॉइंट्स को निष्क्रिय कर देती हैं। HTTP 429, 5xx प्रतिक्रियाएं और नेटवर्क विफलताएं जिटर्ड बैकऑफ़ का उपयोग करती हैं। समाप्त (expired) कार्य समाप्त हो जाते हैं। एक डेड-लेटर रिप्ले मूल delivery_id को बनाए रखता है और समाप्ति और ऑप्ट-आउट स्थिति की फिर से जाँच करता है। प्राप्तियां डुप्लिकेट हो सकती हैं और क्रम से बाहर आ सकती हैं, इसलिए सिस्टम चैनल-विशिष्ट परिवर्तनों के माध्यम से वर्तमान स्थिति प्राप्त करने से पहले कच्चे इवेंट्स को संग्रहीत करता है।

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

• व्यवसाय के लिए "डिलीवर किया गया" का क्या अर्थ है? नियंत्रणीय OTP लक्ष्य प्रदाता स्वीकृति पर समाप्त होना चाहिए क्योंकि ऑफ़लाइन डिवाइस, वाहक और उपयोगकर्ता अनुमतियां प्लेटफ़ॉर्म के बाहर हैं। यदि व्यवसाय को "पढ़ा गया" की आवश्यकता है, तो उसे कवरेज के खुलासे के साथ एक समर्थित चैनल प्राप्ति या क्लाइंट इवेंट की आवश्यकता होती है।
• नोटिफिकेशन प्रकार और प्राथमिकता कौन निर्दिष्ट करता है? सर्वर एक नियंत्रित प्रकार कैटलॉग का मालिक है जो प्रकार को प्राथमिकता, अनुमत चैनलों, टेम्प्लेट और ऑप्ट-आउट नियमों से मैप करता है। कॉलर्स को critical=true भेजने की अनुमति देने से प्रत्येक टीम आपातकालीन लेन के लिए प्रतिस्पर्धा करने लगती है।
• कौन से संदेश शांत घंटों या ऑप्ट-आउट को बायपास कर सकते हैं? केवल उस अपवाद के लिए स्वीकृत ट्रांज़ैक्शन प्रकार ही ऐसा कर सकते हैं। मार्केटिंग प्राथमिकताओं की जाँच चैनल कतारबद्ध करने से ठीक पहले की जाती है, ताकि शेड्यूलिंग के बाद ऑप्ट-आउट करने वाले उपयोगकर्ता को बाहर रखा जा सके।
• क्या क्रॉस-चैनल फ़ेलओवर की अनुमति है? विफल SMS को पुश से बदलने से लागत, पहुंच और उपयोगकर्ता की अपेक्षाएं बदल जाती हैं। नोटिफिकेशन प्रकार द्वारा एक फ़ेलओवर ग्राफ़ कॉन्फ़िगर करें और एक अज्ञात परिणाम से स्पष्ट अस्वीकृति को अलग करें; एक अज्ञात परिणाम के बाद फ़ेलओवर उपयोगकर्ता से दो बार संपर्क कर सकता है।
• किस क्रम (ordering) की आवश्यकता है? एक उपयोगकर्ता के लिए पासवर्ड-रीसेट संदेशों को क्रम की आवश्यकता हो सकती है, जबकि सामान्य सोशल अलर्ट को आमतौर पर वैश्विक क्रम की आवश्यकता नहीं होती है। सिस्टम को क्रमिक (serializing) करने से बचने के लिए केवल (user_id, notification_type) जैसी कुंजियों पर क्रम बनाए रखें।
• प्रतिधारण (retention) और गोपनीयता सीमाएं क्या हैं? संदेश निकाय (bodies) संवेदनशील हो सकते हैं। कतारों में टेम्प्लेट संस्करण और न्यूनतम पैरामीटर रखें, चयनित फ़ील्ड एन्क्रिप्ट करें, प्रतिधारण सीमाएं लागू करें, और कभी भी OTP, पूर्ण फ़ोन नंबर या ईमेल निकाय लॉग न करें।

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

"मैं ड्यूरेबल स्वीकृति, प्रदाता स्वीकृति, डिवाइस डिलीवरी और उपयोगकर्ता द्वारा पढ़ने को अलग-अलग स्थितियों में विभाजित करूँगा। इनग्रेस परमाणु रूप से नोटिफिकेशन और एक आउटबॉक्स लिखता है, फिर 202 लौटाता है। प्राप्तकर्ता फ़ैन-आउट अतुल्यकालिक (asynchronous) है, और प्राथमिकताओं, शांत घंटों, समाप्ति और डिडुप्लिकेशन के लिए प्रेषण के पास नीति की जाँच की जाती है। प्रत्येक चैनल में अलग-अलग ट्रांज़ैक्शनल, सामान्य और बल्क कतारें और उपभोक्ता होते हैं, जिसमें ट्रांज़ैक्शनल ट्रैफ़िक के लिए प्रदाता क्षमता सुरक्षित होती है और निष्क्रिय क्षमता बल्क कार्य को उधार दी जाती है। वर्कर्स एक स्थिर delivery_id के तहत एट-लीस्ट-वन्स कार्यों को प्रोसेस करते हैं, स्थायी, दर-सीमा और क्षणिक विफलताओं को वर्गीकृत करते हैं, और क्षणिक मामलों के लिए जिटर्ड एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं। प्रदाता कॉलबैक को इवेंट्स के रूप में जोड़ा जाता है और एक चैनल स्टेट मशीन के माध्यम से फ़ोल्ड किया जाता है, ताकि क्रम से बाहर भेजा गया इवेंट डिलीवर की गई स्थिति को पीछे न ले जा सके। मैं दो-सेकंड के SLO और बैकलॉग रिकवरी को साबित करने के लिए OTP, डुप्लिकेट कार्यों और पुन: व्यवस्थित कॉलबैक के साथ मार्केटिंग वृद्धि का परीक्षण करूँगा।"

चरण-दर-चरण गहन विश्लेषण

इनग्रेस API किसी SMS या पुश प्रदाता को सिंक्रोनस रूप से कॉल नहीं करता है। यह कॉलर को प्रमाणित करता है, एक नियंत्रित नोटिफिकेशन प्रकार को मान्य करता है, टेम्प्लेट संस्करण को ठीक करता है, न्यूनतम पैरामीटर को मान्य करता है, और एक डेटाबेस लेनदेन में एक नोटिफिकेशन और एक आउटबॉक्स रिकॉर्ड लिखता है:

~~~text POST /v1/notifications { request_id, notification_type, recipients | audience_id, template_version, template_params, schedule_at, expire_at }

202 Accepted { notification_id, accepted_at } ~~~

request_id कॉलर पुनः प्रयासों को डिडुप्लिकेट करता है, notification_id एक व्यावसायिक नोटिफिकेशन की पहचान करता है, और delivery_id एक उपयोगकर्ता-चैनल डिलीवरी की पहचान करता है। वे एक पहचानकर्ता नहीं हो सकते क्योंकि एक नोटिफिकेशन कई उपयोगकर्ताओं और चैनलों तक फ़ैल सकता है। एक आउटबॉक्स रिले इनग्रेस लेनदेन कमिट होने के बाद ही प्रकाशित होता है, जिससे डेटाबेस-कमिट/संदेश-प्रकाशन अंतर समाप्त हो जाता है। 50-मिलियन-प्राप्तकर्ता अभियान के लिए, इनग्रेस एक ऑडियंस-स्नैपशॉट संदर्भ और कर्सर संग्रहीत करता है; यह एक अनुरोध या लेनदेन के अंदर 50 मिलियन पंक्तियाँ नहीं बनाता है।

एक फ़ैन-आउट सेवा स्नैपशॉट को विभाजनों में पढ़ती है और छोटे योजना बैच बनाती है। भेजने के समय के करीब, एक नीति सेवा नोटिफिकेशन-प्रकार के नियमों और वर्तमान उपयोगकर्ता प्राथमिकताओं को लोड करती है, फिर ऑप्ट-आउट, शांत घंटे, चैनल उपलब्धता, आवृत्ति नीति, समाप्ति और फ़ेलओवर क्रम का मूल्यांकन करती है। शांत घंटे उपयोगकर्ता के IANA टाइम ज़ोन का उपयोग करते हैं और डेलाइट-सेविंग परिवर्तनों को संभालते हैं। यदि कोई ज़ोन ज्ञात नहीं है, तो उत्पाद चुपचाप सर्वर समय का उपयोग करने के बजाय एक स्पष्ट डिफ़ॉल्ट का उपयोग करता है। एक फ़िल्टर किए गए कार्य को SUPPRESSED और एक मशीन-पठनीय कारण प्राप्त होता है ताकि सहायता टीम समझा सके कि इसे क्यों नहीं भेजा गया था।

मुख्य डेटा को तीन रिकॉर्डों में विभाजित किया जा सकता है:

~~~text Notification( notificationid, tenantid, notification_type, templateversion, scheduleat, expire_at )

Delivery( deliveryid, notificationid, user_id, channel, trafficclass, state, provider, providermessage_id, attemptcount, nextattemptat, stateversion )

DeliveryEvent( deliveryid, providereventid, eventtype, providertime, receivedat, rawpayloadref ) ~~~

Delivery भौतिक वर्तमान दृश्य (materialized current view) है; DeliveryEvent प्रदाता प्राप्ति तथ्यों को सुरक्षित रखता है। कच्ची सामग्री और व्यक्तिगत डेटा नियंत्रित स्टोरेज में रहते हैं, इवेंट टेबल में केवल एक संदर्भ होता है। जब कोई प्रदाता provider_event_id की आपूर्ति करता है, तो विशिष्टता लागू करें। अन्यथा, डिडुप्लिकेशन के लिए सामान्यीकृत रसीद फ़ील्ड को हैश करें। इवेंट्स लिखने से पहले वेबहुक हस्ताक्षरों को सत्यापित करें और अज्ञात फ़ील्ड्स को संगत रूप से संरक्षित करें; एक नया प्रदाता फ़ील्ड मान्य कॉलबैक को बाधित नहीं करना चाहिए।

कम से कम, इन स्थितियों में अंतर करें:

~~~text ACCEPTED -> PLANNED -> QUEUED -> SENDING -> PROVIDER_ACCEPTED | v DELIVERED -> READ

Terminal side states: SUPPRESSED, EXPIRED, FAILED_PERMANENT ~~~

यह आरेख व्यावसायिक चरणों को व्यक्त करता है, कॉलबैक आगमन क्रम की गारंटी नहीं देता है। एक प्रदाता sent से पहले delivered डिलीवर कर सकता है, और डुप्लिकेट वेबहुक सामान्य हैं। हैंडलर एक आइडमपोटेंट इवेंट जोड़ता है, फिर चैनल, वर्तमान स्थिति और नए इवेंट द्वारा कुंजीबद्ध ट्रांज़िशन टेबल के साथ प्रोजेक्शन को अपडेट करता है। एक देर से आया sent पहले से ही DELIVERED पर मौजूद SMS को पीछे नहीं ले जा सकता है; रीड रिसीट वाला चैनल DELIVERED से READ पर आगे बढ़ सकता है। एक अनमैप्ड इवेंट कच्ची तालिका में रहता है और अनुमानित स्थिति लागू करने के बजाय एक अलर्ट उठाता है।

सेंड डेटा प्लेन कतारों को चैनल और ट्रैफ़िक क्लास द्वारा अलग करता है, जैसे sms.transactional, sms.bulk, और push.transactional। प्रत्येक समूह में स्वतंत्र बैकलॉग-आयु मेट्रिक्स, उपभोक्ता समवर्तीता और पुनः प्रयास कतारें होती हैं। मान लीजिए कि एक SMS प्रदाता अनुबंध प्रति सेकंड 10,000 अनुरोधों की अनुमति देता है। शेड्यूलर ट्रांज़ैक्शनल ट्रैफ़िक के लिए 3,000 प्रति सेकंड की सुरक्षा कर सकता है, बल्क ट्रैफ़िक को अप्रयुक्त क्षमता उधार लेने दे सकता है, और ट्रांज़ैक्शन ट्रैफ़िक बढ़ने पर इसे वापस ले सकता है। ये कॉन्फ़िगरेशन उदाहरण हैं; वास्तविक मान प्रदाता अनुबंधों और लोड परीक्षणों से आते हैं। प्रति-किरायेदार (per-tenant) निष्पक्ष शेड्यूलिंग एक अभियान को बल्क बजट का उपभोग करने से रोकता है, जबकि एजिंग सामान्य कार्य को हमेशा के लिए भूखा रहने से रोकती है।

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

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

त्रुटि वर्गीकरण अगली कार्रवाई निर्धारित करता है:

• अमान्य पैरामीटर, अमान्य टेम्प्लेट, और पुष्टि किए गए अमान्य डिवाइस टोकन स्थायी हैं। FAILED_PERMANENT पर ले जाएं और साक्ष्य द्वारा समर्थित होने पर ही एंडपॉइंट को निष्क्रिय करें। APNs 410 का अर्थ है कि डिवाइस टोकन अब विषय के लिए सक्रिय नहीं है।
• HTTP 429, प्रदाता 5xx प्रतिक्रियाएं, और कनेक्शन विफलताएं आमतौर पर पुनः प्रयास करने योग्य होती हैं। एक्सपोनेंशियल बैकऑफ़, पूर्ण जिटर, अधिकतम प्रयास गणना और समग्र समय सीमा का उपयोग करें। पुनः प्रयास अभी भी चैनल क्षमता नियंत्रण से गुजरते हैं ताकि रिकवरी दूसरा स्पाइक न बनाए।
• प्रमाणीकरण या खाता-कॉन्फ़िगरेशन विफलताएं प्लेटफ़ॉर्म घटनाएं हैं। प्रभावित प्रदाता चैनल को रोकें और सचेत करें; प्रत्येक संदेश का पुनः प्रयास करना विफलता को बढ़ाता है।
• एक OTP या पुराना रिमाइंडर जो expire_at तक पहुँचता है, वह EXPIRED बन जाता है। एक डेड-लेटर रिप्ले अपनी मूल समाप्ति का विस्तार नहीं कर सकता है या डिडुप्लिकेशन को बायपास करने के लिए एक नया delivery_id असाइन नहीं कर सकता है।

प्रदाता स्वीकृति डिवाइस डिलीवरी को साबित नहीं करती है। APNs प्रत्येक POST के लिए एक स्थिति और apns-id लौटाता है; सफलता अनुरोध-स्तरीय सफलता साबित करती है। Firebase भी कतारबद्ध करने या APNs को सौंपने को Sends के रूप में गिनता है। एक SMS प्रदाता बाद में queued, sent, delivered, undelivered, और read स्थितियों की पेशकश कर सकता है, और इसके वेबहुक क्रम से बाहर हो सकते हैं। इसलिए सार्वजनिक API status_reason के साथ एक स्तरित स्थिति लौटाता है। रिपोर्ट अलग से स्वीकृति, प्रदाता-स्वीकृति, अवलोकनीय-डिलीवरी और अवलोकनीय-ओपन दरों की गणना करती हैं। यदि कोई चैनल किसी स्थिति को उजागर नहीं करता है, तो इसे सफलता या विफलता के रूप में गिनने के बजाय अज्ञात रिपोर्ट करें।

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

निर्णायक स्वीकृति परीक्षण यह है कि "एक बल्क वृद्धि OTP में देरी नहीं कर सकती है।" प्रति सेकंड लगभग 232,000 अभियान कार्यों को बनाए रखें, फिर ट्रांज़ैक्शन ट्रैफ़िक जोड़ें। सत्यापित करें कि स्वीकृति से प्रदाता सबमिशन तक OTP p99 दो सेकंड से कम रहे और बल्क बैकलॉग अपनी 15 मिनट की विंडो के भीतर खाली हो जाए। 429 और 5xx प्रतिक्रियाएं इंजेक्ट करें और पुष्टि करें कि बैकऑफ़ पुनः प्रयास तरंगों में सिंक्रनाइज़ नहीं होता है। एक ही कतार कार्य को एक से अधिक बार डिलीवर करें और सत्यापित करें कि यह मूल delivery_id का पुन: उपयोग करता है। delivered -> sent -> delivered क्रम में कॉलबैक भेजें और सत्यापित करें कि स्थिति कभी पीछे नहीं जाती है। भेजने से ठीक पहले ऑप्ट-आउट, डेलाइट-सेविंग परिवर्तन, समाप्त हो चुके डेड लेटर्स और अज्ञात प्रदाता परिणामों को भी कवर करें। वे विफलता-पथ परिणाम "विश्वसनीय" को परीक्षण योग्य बनाते हैं।

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

"मैं चार अलग-अलग परिणामों को परिभाषित करूँगा: ड्यूरेबल प्लेटफ़ॉर्म स्वीकृति, प्रदाता स्वीकृति, अवलोकनीय डिवाइस डिलीवरी, और उपयोगकर्ता द्वारा पढ़ना। API केवल पहले का वादा करता है। यह नोटिफिकेशन और आउटबॉक्स लिखता है, फिर 202 लौटाता है। फ़ैन-आउट अतुल्यकालिक है, और एक स्थिर delivery_id असाइन करने से पहले भेजने के समय के करीब नवीनतम ऑप्ट-आउट, शांत-घंटे, चैनल-उपलब्धता, और समाप्ति नियमों का मूल्यांकन किया जाता है।

प्रति दिन एक अरब चैनल कार्य औसतन लगभग 11,600 प्रति सेकंड होते हैं, जिसमें 20 गुना अभियान शिखर लगभग 232,000 प्रति सेकंड होता है। OTP को दो सेकंड के भीतर प्रदाता तक पहुंचना चाहिए, जबकि मार्केटिंग को 15 मिनट में सुचारू किया जा सकता है। इसलिए मैं कतारों और उपभोक्ताओं को चैनल और ट्रांज़ैक्शनल, सामान्य और बल्क क्लास द्वारा अलग करूँगा, ट्रांज़ैक्शन के लिए प्रदाता क्षमता की रक्षा करूँगा, और बल्क को केवल निष्क्रिय क्षमता उधार लेने दूँगा। प्रत्येक किरायेदार को एक उचित हिस्सा भी मिलता है।

वर्कर्स एट-लीस्ट-वन्स उपभोग मानते हैं। डुप्लिकेट कतार कार्य उसी delivery_id का दावा करता है। स्थायी त्रुटियां रुक जाती हैं, जबकि 429, 5xx, और नेटवर्क विफलताएं समग्र समय सीमा द्वारा बाध्य जिटर्ड बैकऑफ़ का उपयोग करती हैं। एक प्रदाता टाइमआउट ने एक बाहरी साइड इफ़ेक्ट उत्पन्न किया हो सकता है। यदि उपलब्ध हो तो मैं प्रदाता आइडमपोटेंसी कुंजी का पुन: उपयोग करता हूँ; अन्यथा मैं UNKNOWN चिह्नित करता हूँ और एंड-टू-एंड एक्ज़ैक्टली-वन्स का दावा करने के बजाय समाधान करता हूँ।

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

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

• API द्वारा 202 लौटाए जाने पर डिलीवर किया गया रिकॉर्ड करना → केवल ड्यूरेबल स्वीकृति पूर्ण है → ACCEPTED, PROVIDER_ACCEPTED, DELIVERED, और READ को अलग करें।
• सभी कार्यों को एक प्राथमिकता कतार में रखना → बल्क बैकलॉग अभी भी डिस्क, उपभोक्ताओं और प्रदाता कोटा को साझा करता है → नियंत्रित उधारी के साथ चैनल और ट्रैफ़िक क्लास द्वारा संसाधनों को अलग करें।
• क्रिटिकल ट्रैफ़िक को सभी सीमाओं को बायपास करने देना → असामान्य OTP ट्रैफ़िक प्लेटफ़ॉर्म और प्रदाता को ओवरलोड कर सकता है → ट्रांज़ैक्शन ट्रैफ़िक को अपनी सीमा, अलर्ट और किरायेदार निष्पक्षता दें।
• यह दावा करना कि उपयोगकर्ता को ठीक एक बार प्राप्त होता है क्योंकि कतार कम से कम एक बार है → एक प्रदाता कॉल सफल हो सकती है जबकि उसकी प्रतिक्रिया खो जाती है → delivery_id द्वारा आंतरिक कार्य को आइडमपोटेंट बनाएं, अज्ञात बाहरी परिणामों का समाधान करें, और डुप्लिकेट जोखिम का खुलासा करें।
• प्रत्येक त्रुटि का तुरंत पुनः प्रयास करना → स्थायी त्रुटियां क्षमता बर्बाद करती हैं और 429/5xx विफलताएं एक पुनः प्रयास तूफ़ान बनाती हैं → स्थायी, क्षणिक, थ्रॉटलिंग और प्लेटफ़ॉर्म कॉन्फ़िगरेशन विफलताओं को वर्गीकृत करें; जिटर के साथ क्षणिक मामलों को पीछे हटाएं।
• वर्तमान स्थिति को सीधे अधिलेखित करना → एक आउट-ऑफ-ऑर्डर कॉलबैक डिलीवर की गई स्थिति को वापस भेजे गए में बदल सकता है → पहले आइडमपोटेंट इवेंट्स को बनाए रखें, फिर चैनल ट्रांज़िशन टेबल के साथ प्रोजेक्शन को अपडेट करें।
• शेड्यूलिंग समय पर उपयोगकर्ता प्राथमिकताओं को फ़्रीज़ करना → बाद में ऑप्ट-आउट करने वाले को अभी भी मार्केटिंग प्राप्त होती है → चैनल कतारबद्ध करने के करीब प्राथमिकताओं और अनुपालन नियमों की फिर से जाँच करें।
• डेड-लेटर रिप्ले के दौरान एक नई ID असाइन करना → डिडुप्लिकेशन बायपास हो जाता है और बासी नोटिफिकेशन्स भेजे जा सकते हैं → मूल delivery_id का पुन: उपयोग करें और ऑप्ट-आउट और समाप्ति की फिर से जाँच करें।
• सरलता के लिए वैश्विक क्रम का उपयोग करना → असंबद्ध उपयोगकर्ता एक-दूसरे को ब्लॉक करते हैं और एक विभाजन थ्रूपुट को सीमित करता है → केवल उस स्थानीय क्रम को सुरक्षित रखें जिसकी उपयोगकर्ता-नोटिफिकेशन प्रकार को वास्तव में आवश्यकता होती है।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: पचास मिलियन उपयोगकर्ता स्थानीय समयानुसार सुबह 9:00 बजे अभियान चाहते हैं। क्या बदलता है?

फ़ैन-आउट के दौरान, IANA टाइम ज़ोन और स्थानीय तिथि के अनुसार समय बकेट बनाएं, फिर उनकी विंडो से पहले दर-नियंत्रित बैच तैयार करें। घंटे पर प्रत्येक कार्य को जारी करने के बजाय प्रत्येक लक्ष्य विंडो के भीतर जिटर जोड़ें। डेलाइट-सेविंग परिवर्तनों के दौरान गैर-मौजूद या दोहराए गए स्थानीय समय के लिए उत्पाद व्यवहार को परिभाषित करें, जैसे कि अगले मान्य पल में जाना और प्रति दिन एक बार से अधिक नहीं भेजना। "9:00 a.m." का अर्थ प्रदाता-सबमिशन विंडो होना चाहिए क्योंकि डिवाइस डिस्प्ले प्लेटफ़ॉर्म नियंत्रण से बाहर रहता है।

अनुवर्ती 2: प्रदाता ने सफलता लौटाई लेकिन कभी डिलीवरी रसीद नहीं भेजी। स्थिति क्या है?

PROVIDER_ACCEPTED बनाए रखें; इसे DELIVERED में पदोन्नत न करें। चैनल की अवलोकन विंडो के बाद, सिस्टम संचालन के लिए DELIVERY_UNKNOWN को उजागर कर सकता है, लेकिन अज्ञात को विफलता के रूप में नहीं गिना जाना चाहिए। यदि प्रदाता एक क्वेरी API या समग्र रिपोर्ट प्रदान करता है, तो अतुल्यकालिक रूप से समाधान करें और उस डेटा की देरी और कवरेज का खुलासा करें।

अनुवर्ती 3: क्या होगा यदि delivered कॉलबैक sent से पहले आता है?

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

अनुवर्ती 4: क्या दो SMS प्रदाता स्वचालित रूप से फ़ेलओवर कर सकते हैं?

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

अनुवर्ती 5: आप कैसे साबित करते हैं कि प्राथमिकता पृथक्करण काम करता है?

एक बंद लोड परीक्षण का उपयोग करें जो तीन दबावों को जोड़ता है: एक निरंतर बल्क बैकलॉग, एक हॉट किरायेदार, और बार-बार प्रदाता 429 प्रतिक्रियाएं। स्वीकृति के लिए OTP प्रदाता-सबमिशन p99 दो सेकंड से कम होना चाहिए, ट्रांज़ैक्शन उपभोक्ताओं पर कोई बल्क कार्य नहीं होना चाहिए, कुल प्रदाता दर कॉन्फ़िगरेशन के भीतर होनी चाहिए, और बल्क रिकवरी 15 मिनट की समय सीमा के भीतर होनी चाहिए। फिर एक ट्रांज़ैक्शन-उपभोक्ता विभाजन को विफल करें और पुष्टि करें कि शेष इंस्टेंस संरक्षित क्षमता को संभाल लेते हैं। केवल औसत थ्रूपुट पृथक्करण को साबित नहीं कर सकता है।