बहु-चैनल नोटिफिकेशन सिस्टम: टेम्पलेट्स, रिट्राई, प्राथमिकताएँ

एक सिंगल नोटिफिकेशन सिस्टम क्या हल करता है

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

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

ज्यादातर टीमों को वही बुनियादी आधार चाहिए, चाहे उन्होंने किसी भी चैनल से शुरुआत की हो: वर्ज़न किए हुए टेम्पलेट जिनमें वेरिएबल हों, डिलिवरी स्थिति ट्रैकिंग ("sent, delivered, failed, why"), समझदारी वाले रिट्राई और फ़ॉलबाक्स, सहमति और शांत घंटों के साथ उपयोगकर्ता प्राथमिकताएँ, और एक ऑडिट ट्रेल ताकि सपोर्ट अनुमान न लगाए।

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

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

मूल अवधारणाएँ और एक सरल डेटा मॉडल

एक बहु-चैनल नोटिफिकेशन सिस्टम तब प्रबंधनीय रहता है जब आप "क्यों सूचित कर रहे हैं" को "हम इसे कैसे भेजते हैं" से अलग रखते हैं। इसका मतलब है कुछ साझा ऑब्जेक्ट्स और केवल वहीं चैनल-विशिष्ट विवरण जहाँ वास्तव में फर्क पड़ता है।

एक इवेंट से शुरुआत करें। इवेंट एक नामित ट्रिगर है जैसे order_shipped या password_reset। नामों को सुसंगत रखें: लोअरकेस, अंडरस्कोर और जब उपयुक्त हो तो past tense। इवेंट को उस स्थिर समझौते के रूप में मानें जिस पर टेम्पलेट्स और प्राथमिकता नियम निर्भर करते हैं।

एक इवेंट से, एक नोटिफिकेशन रिकॉर्ड बनाएँ। यह उपयोगकर्ता-समक्ष इरादा है: किसके लिए है, क्या हुआ, और किस डेटा की ज़रूरत है सामग्री रेंडर करने के लिए (ऑर्डर नंबर, डिलिवरी तिथि, रीसेट कोड)। यहां साझा फ़ील्ड्स जैसे user_id, event_name, locale, priority और scheduled_at स्टोर करें।

फिर चैनल-प्रति मैसेजेस में विभाजित करें। एक नोटिफिकेशन 0 से 3 मैसेज बना सकता है (ईमेल, SMS, Telegram)। मैसेजेस में चैनल-विशिष्ट फ़ील्ड्स होते हैं जैसे गंतव्य (ईमेल पता, फोन, Telegram chat_id), template_id, और रेंडर की गई सामग्री (ईमेल के लिए subject/body, SMS के लिए संक्षिप्त टेक्स्ट)।

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

एक सरल मॉडल अक्सर चार तालिकाओं या कलेक्शंस में फिट बैठता है:

• Event (अनुमत इवेंट नामों और डिफ़ॉल्ट्स का कैटलॉग)
• Notification (एक प्रति उपयोगकर्ता इरादा)
• Message (हर चैनल के लिए एक)
• DeliveryAttempt (हर भेजने के प्रयास के लिए एक)

idempotency की योजना शुरू में बनाएं। प्रत्येक नोटिफिकेशन को एक निर्धारक कुंजी दें जैसे (event_name, user_id, external_ref) ताकि upstream सिस्टम के रिट्राई डुप्लिकेट न बनाएं। अगर कोई वर्कफ़्लो स्टेप फिर से चलता है, तो idempotency कुंजी उपयोगकर्ता को दो SMS मिलने से रोकेगी।

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

एक व्यावहारिक एंड-टू-एंड फ़्लो (कदम-दर-कदम)

एक बहु-चैनल नोटिफिकेशन सिस्टम तब सबसे अच्छा काम करता है जब वह "क्या भेजना है तय करना" और "इसे भेजना" को अलग रखता है। इससे आपकी एप तेज़ रहती है और फेल्यर्स को संभालना आसान होता है।

एक व्यावहारिक फ़्लो इस तरह दिखता है:

1. एक इवेंट प्रोड्यूसर नोटिफिकेशन रिक्वेस्ट बनाता है। यह "password reset," "invoice paid," या "ticket updated" हो सकता है। रिक्वेस्ट में user ID, message type और context डेटा (order number, amount, support agent name) शामिल होता है। ऑडिट ट्रेल के लिए रिक्वेस्ट को तुरंत स्टोर करें।

2. एक राउटर उपयोगकर्ता और मैसेज नियम लोड करता है। यह उपयोगकर्ता प्राथमिकताएँ (अनुमत चैनल, opt-ins, quiet hours) और संदेश नियम (उदाहरण: सुरक्षा अलर्ट्स को पहले ईमेल कोशिश करनी चाहिए) देखता है। राउटर चैनल प्लान तय करता है, जैसे Telegram, फिर SMS, फिर ईमेल।

3. सिस्टम चैनल-प्रति सेंड जॉब्स एनक्यू करता है। हर जॉब में एक टेम्पलेट की कुंजी, चैनल और वेरिएबल्स होते हैं। जॉब्स क्यू में जाते हैं ताकि उपयोगकर्ता की क्रिया भेजने से ब्लॉक न हो।

4. चैनल वर्कर्स प्रोवाइडर्स के माध्यम से डिलीवर करते हैं। ईमेल SMTP या ईमेल API पर जाता है, SMS SMS गेटवे पर जाता है, Telegram आपके बॉट के माध्यम से जाता है। वर्कर्स idempotent होने चाहिए, ताकि एक ही जॉब को फिर से चलाने पर डुप्लिकेट न भेजे जाएँ।

5. स्थिति अपडेट्स एक ही जगह वापस फ़्लो होती हैं। वर्कर्स queued, sent, failed और जहाँ उपलब्ध हो delivered रिकॉर्ड करते हैं। अगर कोई प्रोवाइडर केवल "accepted" कन्फर्म करता है, तो उसे भी रिकॉर्ड करें और delivered से अलग तरह से ट्रीट करें।

6. फ़ॉलबाक्स और रिट्राई उसी स्टेट से चलते हैं। अगर Telegram फेल हो जाता है, तो राउटर (या एक retry worker) अगले समय पर SMS शेड्यूल कर सकता है बिना संदर्भ खोए।

उदाहरण: एक उपयोगकर्ता अपना पासवर्ड बदलता है। आपका बैकएंड एक रिक्वेस्ट इमिट करता है जिसमें उपयोगकर्ता और IP पता होता है। राउटर देखता है कि उपयोगकर्ता Telegram पसंद करता है, लेकिन quiet hours रात में उसे ब्लॉक कर रहे हैं, इसलिए वह अभी ईमेल शेड्यूल करता है और सुबह Telegram भेजने के लिए शेड्यूल करता है, दोनों को उसी नोटिफिकेशन रिकॉर्ड के तहत ट्रैक करते हुए।

यदि आप इसे AppMaster में लागू कर रहे हैं, तो रिक्वेस्ट, जॉब्स और स्टेटस टेबल्स को Data Designer में रखें और राउटिंग तथा रिट्राई लॉजिक को Business Process Editor में व्यक्त करें, साथ ही भेजना असिंक्रोनसली करें ताकि UI उत्तरदायी रहे।

चैनलों के पार काम करने वाली टेम्पलेट संरचना

एक अच्छा टेम्पलेट सिस्टम एक विचार से शुरू होता है: आप किसी इवेंट के बारे में सूचित कर रहे हैं, न कि "एक ईमेल भेज रहे हैं" या "एक SMS भेज रहे हैं"। प्रत्येक इवेंट के लिए एक टेम्पलेट बनाएं (Password reset, Order shipped, Payment failed), फिर उसी इवेंट के अंतर्गत चैनल-विशिष्ट वेरिएंट स्टोर करें।

हर चैनल वेरिएंट में एक ही वेरिएबल्स रखें। अगर ईमेल first_name और order_id का उपयोग करता है, तो SMS और Telegram को वही नाम उपयोग करने चाहिए। इससे छोटे बग्स जैसे किसी चैनल पर खाली दिखना रोका जाता है।

एक सरल, दोहराने योग्य टेम्पलेट आकार

प्रत्येक इवेंट के लिए, प्रति चैनल छोटे फील्ड्स सेट करें:

• Email: subject, preheader (वैकल्पिक), HTML बॉडी, टेक्स्ट फॉलबैक
• SMS: प्लेन टेक्स्ट बॉडी
• Telegram: प्लेन टेक्स्ट बॉडी, साथ ही वैकल्पिक बटन या छोटी मेटाडेटा

केवल वही चीज़ चैनलों के अनुसार बदलनी चाहिए जो फॉर्मैटिंग से संबंधित है, अर्थ से नहीं।

SMS के लिए विशेष नियम चाहिए क्योंकि यह संक्षिप्त है। पहले से तय करें कि कंटेंट लंबा होने पर क्या होगा और इसे सुसंगत रखें: चरित्र सीमा सेट करें, ट्रंकेशन नियम चुनें (कट करके ... जोड़ना या वैकल्पिक पंक्तियों को पहले ड्रॉप करना), लंबे URLs और अतिरिक्त विराम चिह्न से बचें, और मुख्य कार्रवाई को पहले रखें (कोड, डेडलाइन, अगला कदम)।

बिजनेस लॉजिक कॉपी किए बिना लोकेल्स

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

एक प्रीव्यू मोड बहुत काम आता है। सैंपल डेटा (लंबे नाम जैसे एज केस शामिल) के साथ टेम्पलेट्स रेंडर करके सपोर्ट वेरिएंट्स की जांच कर सकता है इससे पहले कि वे लाइव जाएँ।

भरोसेमंद और डिबग करने योग्य डिलिवरी स्टेटस

एक नोटिफिकेशन तभी उपयोगी है जब आप बाद में यह सवाल उत्तर दे सकें: इसके साथ क्या हुआ? एक अच्छा बहु-चैनल नोटिफिकेशन सिस्टम उस संदेश को अलग करता है जिसे आप भेजना चाहते थे और प्रत्येक डिलिवरी प्रयास को जो आपने किया।

शुरू करें एक छोटे सेट साझा स्टेटस के साथ जो ईमेल, SMS और Telegram में एक ही मतलब रखें:

• queued: आपके सिस्टम द्वारा स्वीकार किया गया, वर्कर के लिए प्रतीक्षा
• sending: एक डिलिवरी प्रयास प्रगति में है
• sent: प्रोवाइडर API को सफलतापूर्वक सौंपा गया
• failed: प्रयास एक ऐसी त्रुटि पर समाप्त हुआ जिस पर आप कार्य कर सकते हैं
• delivered: आपके पास सबूत है कि यह उपयोगकर्ता तक पहुंचा (जहाँ संभव हो)

इन स्टेटस को मुख्य मैसेज रिकॉर्ड पर रखें, लेकिन हर प्रयास का इतिहास एक हिस्ट्री टेबल में ट्रैक करें। यही हिस्ट्री डिबगिंग को आसान बनाती है: प्रयास #1 फेल हुआ (टाइमआउट), प्रयास #2 सफल हुआ, या SMS ठीक था जबकि ईमेल बाउंस हो रहा था।

प्रति प्रयास क्या स्टोर करें

प्रोवाइडेर्स के रिस्पॉन्स को सामान्यीकृत करें ताकि आप अलग शब्दों का उपयोग करने वाले प्रोवाइडरों के साथ भी मुद्दों को खोज और ग्रुप कर सकें।

• provider_name और provider_message_id
• response_code (एक सामान्यीकृत कोड जैसे TIMEOUT, INVALID_NUMBER, BOUNCED)
• raw_provider_code और raw_error_text (सपोर्ट के मामलों के लिए)
• started_at, finished_at, duration_ms
• channel (email, sms, telegram) और destination (मास्क किया हुआ)

आंशिक सफलता की योजना बनाएं। एक नोटिफिकेशन तीन चैनल मैसेज बना सकता है जो एक ही parent_id और बिजनेस संदर्भ (order_id, ticket_id, alert_type) साझा करते हैं। अगर SMS भेजा गया लेकिन ईमेल फेल हुआ, तो आप पूरी कहानी एक जगह चाहते हैं, तीन अलग घटनाओं के रूप में नहीं।

"delivered" का असली मतलब

"Sent" का मतलब "delivered" नहीं होता। Telegram के लिए, आप केवल जान सकते हैं कि API ने संदेश स्वीकार किया। SMS और ईमेल के लिए, डिलिवरी अक्सर वेबहुक या प्रोवाइडर कॉलबैक्स पर निर्भर करती है, और सभी प्रोवाइडर एक जैसे भरोसेमंद नहीं होते।

प्रत्येक चैनल के लिए पहले ही delivered को परिभाषित करें। जहाँ वेबहुक-कन्फर्म्ड डिलिवरी उपलब्ध हो, उसे इस्तेमाल करें; अन्यथा delivered को अज्ञात मानें और sent रिपोर्ट करते रहें। इससे आपकी रिपोर्टिंग ईमानदार रहती है और सपोर्ट के उत्तर सुसंगत रहते हैं।

रिट्राई, फ़ॉलबाक्स, और कब प्रयास रोकना है

रिट्राई वह जगह है जहाँ नोटिफिकेशन सिस्टम अक्सर गलत होते हैं। बहुत तेज़ रिट्राई करने से आप स्टॉर्म बना देते हैं। हमेशा रिट्राई करने से डुप्लिकेट और सपोर्ट सिरदर्द होंगे। लक्ष्य सरल है: जब वास्तविक काम करने की संभावना हो तब फिर से प्रयास करें, और जब न हो तब बंद कर दें।

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

एक व्यावहारिक रिट्राई प्लान बंधित और बैकऑफ़ उपयोग करता है:

• प्रयास 1: अभी भेजें
• प्रयास 2: 30 सेकंड बाद
• प्रयास 3: 2 मिनट बाद
• प्रयास 4: 10 मिनट बाद
• अलर्ट्स के लिए अधिकतम आयु के बाद स्टॉप करें (उदाहरण: 30-60 मिनट)

रुकना आपके डेटा मॉडल में वास्तव में मौजूद होना चाहिए। रिट्राई लिमिट पार होने पर मैसेज को dead-letter (या failed-permanently) के रूप में मार्क करें। अंतिम एरर कोड और एक छोटा एरर मैसेज रखें ताकि सपोर्ट बिना अनुमान के कार्रवाई कर सके।

सफलता के बाद बार-बार भेजने से रोकने के लिए idempotency का प्रयोग करें। प्रत्येक लॉजिकल मैसेज के लिए एक idempotency कुंजी बनाएं (अक्सर notification_id + user_id + channel)। अगर प्रोवाइडर लेट रेस्पॉन्स भेजता है और आप रिट्राई करते हैं, तो दूसरे प्रयास को डुप्लिकेट के रूप में पहचाना जाना चाहिए और उसे स्किप किया जाना चाहिए।

फ़ॉलबाक्स सोच-समझकर होने चाहिए, पैनिक में स्वचालित नहीं। गंभीरता और समय के आधार पर एस्केलेशन नियम परिभाषित करें। उदाहरण: पासवर्ड रीसेट को दूसरे चैनल पर फ़ॉलबैक नहीं करना चाहिए (प्राइवेसी रिस्क), पर प्रोडक्शन इन्सिडेंट अलर्ट दो असफल Telegram प्रयासों के बाद SMS आज़मा सकता है, फिर 10 मिनट बाद ईमेल।

उपयोगकर्ता प्राथमिकताएँ, सहमति, और क्वाइट ऑवर्स

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

एक ऐसी प्राथमिकता मॉडल से शुरुआत करें जो तब भी काम करे जब कोई चैनल उपलब्ध न हो। एक उपयोगकर्ता के पास ईमेल हो सकता है पर फोन नंबर नहीं, या उन्होंने Telegram कनेक्ट नहीं किया हो। आपका सिस्टम इसे सामान्य समझे, त्रुटि नहीं।

अधिकांश सिस्टम को कुछ संक्षिप्त फ़ील्ड्स चाहिए: नोटिफिकेशन प्रकार (security, marketing, billing), प्रकार के अनुसार अनुमत चैनल (email, SMS, Telegram), प्रति चैनल सहमति (तिथि/समय, स्रोत, और प्रमाण यदि आवश्यक), चैनल के अनुसार opt-out कारण (उपयोगकर्ता विकल्प, बाउंस्ड ईमेल, "STOP" उत्तर), और quiet hours नियम (शुरू/समाप्त और उपयोगकर्ता का टाइमज़ोन)।

क्वाइट ऑवर्स वही जगह है जहाँ सिस्टम अक्सर टूटते हैं। उपयोगकर्ता का टाइमज़ोन स्टोर करें (केवल ऑफ़सेट नहीं) ताकि डे लाईट सेविंग बदलने से कोई आश्चर्य न हो। जब संदेश क्वाइट ऑवर्स में शेड्यूल होता है, तो उसे फेल न मानें। उसे deferred के रूप में मार्क करें और अगला अनुमत भेजने का समय चुनें।

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

उदाहरण: पासवर्ड रीसेट को सबसे तेज़ अनुमत चैनल पर तुरंत भेजना चाहिए। साप्ताहिक डाइजेस्ट सुबह तक इंतज़ार करना चाहिए और SMS तब तक छोड़ देना चाहिए जब तक उपयोगकर्ता ने स्पष्ट रूप से उसे सक्षम न किया हो।

ऑपरेशन्स: मॉनिटरिंग, लॉग्स और सपोर्ट वर्कफ़्लोज़

जब नोटिफिकेशन ईमेल, SMS और Telegram को छूते हैं, तो सपोर्ट टीमों को तेज़ उत्तर चाहिए: क्या हमने भेजा, क्या यह पहुँचा, और क्या फेल हुआ? एक बहु-चैनल नोटिफिकेशन सिस्टम को एक ही जगह जैसा महसूस होना चाहिए जहाँ जांच की जाए, भले ही पीछे कई प्रोवाइडर हों।

एक सरल एडमिन व्यू से शुरुआत करें जिसे कोई भी उपयोग कर सके। इसे user, event type, status और समय विंडो से खोजने योग्य बनाएं, और नवीनतम प्रयास पहले दिखाएँ। हर पंक्ति में चैनल, प्रोवाइडरレス्पॉन्स और अगला नियोजित कदम (रिट्राई, फ़ॉलबैक, या रोका गया) दिखाएं।

समस्याएँ जल्दी पकड़ने के लिए मैट्रिक्स

आउटेज अक्सर एक साफ त्रुटि के रूप में नहीं आते। कुछ संख्याएँ ट्रैक करें और नियमित रूप से उनकी समीक्षा करें:

• चैनल के अनुसार सेंड रेट (मैसेज प्रति मिनट)
• प्रोवाइडर और फेल्योर कोड के अनुसार फेल्योर रेट
• रिट्राई दर (कितने मैसेजों को दूसरे प्रयास की ज़रूरत पड़ी)
• डिलिवर करने का समय (queued से delivered, p50 और p95)
• ड्रॉप रेट (उपयोगकर्ता प्राथमिकताओं, सहमति या अधिकतम रिट्राई की वजह से रोके गए)

सब कुछ को कोरिलेट करें। जब इवेंट होता है तो एक correlation ID जनरेट करें (जैसे "invoice overdue") और इसे टेम्पलेटिंग, क्यूइंग, प्रोवाइडर कॉल्स और स्टेटस अपडेट्स में पास करें। लॉग्स में, वह ID उस धागे के रूप में काम करेगी जिसे तबफ़ॉलो किया जा सकता है जब एक इवेंट कई चैनलों में फैले।

सपोर्ट-फ्रेंडली रिप्ले बिना आश्चर्यों के

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

नोटिफिकेशन के लिए सुरक्षा और गोपनीयता के बुनियादी नियम

एक बहु-चैनल नोटिफिकेशन सिस्टम व्यक्तिगत डेटा (ईमेल, फोन नंबर, चैट IDs) को छूता है और अक्सर संवेदनशील पलों को कवर करता है (लॉगिन, भुगतान, सपोर्ट)। मान लें कि हर संदेश बॉडी और हर लॉग लाइन बाद में देखी जा सकती है, फिर डिजाइन ऐसा करें कि आप क्या स्टोर करते हैं और कौन क्या देख सकता है, उसे सीमित करें।

जहाँ तक संभव हो, टेम्पलेट्स में संवेदनशील डेटा न रखें। एक टेम्पलेट पुन:उपयोग योग्य और साधारण होना चाहिए: "Your code is {{code}}" ठीक है, पर पूरा अकाउंट विवरण, लंबे टोकन या कुछ भी जो अकाउंट पर कब्ज़ा कर सकता है, शामिल न करें। अगर कोई संदेश एक-बार कोड या रीसेट टोकन शामिल करना ही चाहिए, तो केवल वह रखें जो सत्यापित करने के लिए ज़रूरी हो (उदाहरण के लिए, एक हैश और एक्सपायरी), न कि कच्चा मान।

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

अधिकांश घटनाओं को रोकने वाले न्यूनतम नियंत्रण

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

एक व्यावहारिक उदाहरण: अगर पासवर्ड रीसेट SMS फेल हो और आप Telegram पर फ़ॉलबैक करते हैं, तो प्रयास, प्रोवाइडर स्थिति, और मास्क्ड प्राप्तकर्ता स्टोर करें, पर रीसेट लिंक को अपने डेटाबेस या लॉग्स में स्टोर करने से बचें।

उदाहरण परिदृश्य: एक अलर्ट, तीन चैनल, वास्तविक परिणाम

एक ग्राहक, Maya, के पास दो नोटिफिकेशन प्रकार सक्षम हैं: Password reset और New login। वह पहले Telegram पसंद करती है, फिर ईमेल। उसने केवल पासवर्ड रीसेट के लिए SMS को फ़ॉलबैक के रूप में सक्षम किया हुआ है।

एक शाम, Maya पासवर्ड रीसेट अनुरोध करती है। सिस्टम एक सिंगल नोटिफिकेशन रिकॉर्ड बनाती है जिसमें स्थिर ID होता है, फिर उसे उसकी वर्तमान प्राथमिकताओं के आधार पर चैनल प्रयासों में विस्तारित करती है।

Maya को जो दिखता है वह सरल है: कुछ सेकंड में Telegram संदेश आता है जिसमें एक संक्षिप्त रीसेट कोड और समाप्ति समय होता है। कुछ भी और नहीं आता क्योंकि Telegram सफल रहा और किसी फ़ॉलबैक की ज़रूरत नहीं थी।

सिस्टम जो रिकॉर्ड करता है वह अधिक विस्तृत है:

• Notification: type=PASSWORD_RESET, user_id=Maya, template_version=v4
• Attempt #1: channel=TELEGRAM, status=SENT फिर DELIVERED
• कोई ईमेल या SMS प्रयास बनाए नहीं गए (नीति: पहली सफलता के बाद रोकें)

उस सप्ताह बाद में, एक नया लॉगिन अलर्ट नए डिवाइस से ट्रिगर होता है। Maya की लॉगिन अलर्ट प्राथमिकताएँ केवल Telegram हैं। सिस्टम Telegram भेजता है, पर Telegram प्रोवाइडर अस्थायी त्रुटि लौटाता है। सिस्टम बैकऑफ़ के साथ दो बार रिट्राई करता है, फिर प्रयास को FAILED के रूप में मार्क कर देता है और रोक देता है (इस अलर्ट प्रकार के लिए कोई फ़ॉलबैक अनुमत नहीं)।

अब एक वास्तविक विफलता: Maya फिर से पासवर्ड रीसेट अनुरोध करती है जबकि यात्रा कर रही है। Telegram भेजा जाता है, पर SMS फ़ॉलबैक इसलिए कॉन्फ़िगर है कि अगर Telegram 60 सेकंड में डिलिवर न करे तो SMS भेजा जाए। SMS प्रोवाइडर टाइमआउट हो जाता है। सिस्टम टाइमआउट रिकॉर्ड करता है, एक बार रिट्राई करता है, और दूसरा प्रयास सफल होता है। Maya को एक मिनट बाद SMS कोड मिल जाता है।

जब Maya सपोर्ट से संपर्क करती है, वे user और समय विंडो से खोजते हैं और तुरंत प्रयास इतिहास देखते हैं: टाइमस्टैम्प, प्रोवाइडर रिस्पॉन्स कोड, रिट्राई काउंट, और अंतिम परिणाम।

त्वरित चेकलिस्ट, सामान्य गलतियाँ, और आगे के कदम

एक बहु-चैनल नोटिफिकेशन सिस्टम चलाने में आसान तब होता है जब आप दो सवालों का तेज़ उत्तर दे सकें: "हमने ठीक क्या भेजने की कोशिश की?" और "उसके बाद क्या हुआ?" इस चेकलिस्ट का इस्तेमाल करें इससे पहले कि आप और चैनल या इवेंट जोड़ें।

त्वरित चेकलिस्ट

• स्पष्ट इवेंट नाम और ओनरशिप (उदा., invoice.overdue बिलिंग द्वारा)
• टेम्पलेट वेरिएबल्स एक बार परिभाषित करें (आवश्यक बनाम वैकल्पिक, डिफ़ॉल्ट्स, फॉर्मैटिंग नियम)
• स्टेटस पहले से सहमत हों (created, queued, sent, delivered, failed, suppressed) और हर एक का अर्थ क्या है
• रिट्राई सीमाएँ और बैकऑफ़ (max attempts, spacing, stop rule)
• रिटेंशन नियम (कितनी देर तक मैसेज बॉडी, प्रोवाइडर रिस्पॉन्स और स्टेटस इतिहास रखें)

अगर आप केवल एक चीज़ करेंगे, तो "sent" और "delivered" के बीच का फर्क सादा शब्दों में लिखें। Sent वह है जो आपका सिस्टम कर चुका है। Delivered वह है जो प्रोवाइडर रिपोर्ट करता है (और यह देर से आ सकता है या गायब भी हो सकता है)। इन दोनों को मिलाने से सपोर्ट टीमें और स्टेकहोल्डर्स भ्रमित होंगे।

टाली जाने वाली सामान्य गलतियाँ

• Sent को सफलता मानना और बढ़ा-चढ़ा कर डिलिवरी रेट रिपोर्ट करना
• चैनल-विशिष्ट टेम्पलेट्स को अलग छोड़ देना जब तक ईमेल, SMS और Telegram एक-दूसरे से विरोध न करने लगें
• idempotency के बिना रिट्राई करना, जिससे प्रोवाइडर टाइमआउट के बाद स्वीकार करने पर डुप्लिकेट्स भेजे जाएँ
• हमेशा रिट्राई करना, अस्थायी आउटेज को शोर में बदल देना
• "बस हो सकता है" के नाम पर लॉग्स और स्टेटस रिकॉर्ड्स में बहुत व्यक्तिगत डेटा स्टोर करना

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

यदि आप हर भाग को हैंड-कोड किए बिना बनाना चाहते हैं, तो AppMaster (appmaster.io) कोर हिस्सों के लिए एक व्यावहारिक विकल्प है: Data Designer में इवेंट्स, टेम्पलेट्स और डिलिवरी प्रयास मॉडल करें, Business Process Editor में राउटिंग और रिट्राई लागू करें, और ईमेल, SMS और Telegram को इंटीग्रेशन के रूप में कनेक्ट करते हुए स्टेटस ट्रैकिंग को एक जगह रखें।