संक्षेप (टीएल;डीआर)
- समस्या: दर्जनों अंदरूनी सेवाएं उपयोगकर्ताओं को कुछ न कुछ बताना चाहती हैं। साझा मंच के बिना हर सेवा एपीएनएस, ईमेल प्रदाता और एसएमएस गेटवे से अलग-अलग जुड़ती है, उपयोगकर्ता की पसंद को अपने तरीके से नजरअंदाज करती है, और तब तक दोबारा कोशिश करती है जब तक उपयोगकर्ता को एक ही संदेश तीन बार न मिल जाए।
- डिजाइन: एक ही सूचना एपीआई दोहराव रोकने वाली कुंजी के साथ अनुरोध लेती है, पसंद, संपर्क और शांत घंटे जांचती है, और हर चैनल की कतार में बांटती है। चैनल वर्कर टेम्पलेट भरते हैं, प्रदाताओं को बुलाते हैं, अस्थायी विफलताओं पर बेतरतीब अंतराल के साथ दोबारा कोशिश करते हैं, बाकी को मृत संदेश कतार में भेजते हैं, और अमान्य टोकन साफ करते हैं। प्रदाताओं की रसीदें डिलीवरी लॉग में जाती हैं।
- नतीजा: कम से कम एक बार वाली डिलीवरी जो उपयोगकर्ता को ठीक एक बार लगती है, अलग-अलग विफल होने वाले चैनल, ऐसे अभियान जो पासवर्ड रीसेट का रास्ता नहीं रोक सकते, और "क्या उपयोगकर्ता को मिला?" का जवाब देने की एक जगह।
सूचनाएं उत्पाद का वह हिस्सा हैं जो उत्पाद से बाहर निकल जाता है। वे लॉक स्क्रीन और इनबॉक्स में उतरती हैं, ध्यान के लिए होड़ करती हर चीज के बीच। इन्हें गलत करें तो उपयोगकर्ता बग रिपोर्ट नहीं भेजते; वे सूचनाएं बंद कर देते हैं, और आप वह चैनल हमेशा के लिए खो देते हैं।
यह लेख वह साझा मंच डिजाइन करता है जो "एक ऑर्डर भेजा गया" और "एक फोन बजा" के बीच बैठता है।
जरूरतें
कार्यात्मक
- चैनल: मोबाइल पुश (आईओएस और एंड्रॉयड), ईमेल, एसएमएस, और वैकल्पिक रूप से ऐप के अंदर।
- भेजने वाली सेवाएं एक अर्थपूर्ण घटना भेजती हैं ("ऑर्डर भेजा गया", "पासवर्ड रीसेट"), पहले से तैयार संदेश नहीं।
- हर श्रेणी और चैनल की पसंद, सदस्यता छोड़ना और शांत घंटों का सम्मान।
- हर सूचना प्रकार और भाषा के टेम्पलेट।
- हर सूचना की डिलीवरी स्थिति, जिसे सहायता टीमें देख सकें।
गैर-कार्यात्मक
- लेनदेन वाले संदेश (पासवर्ड रीसेट, सुरक्षा चेतावनी) सेकंडों में पहुंचें, मार्केटिंग की बौछार के बीच भी।
- किसी अंदरूनी दोबारा कोशिश के कारण एक ही सूचना एक उपयोगकर्ता को दो बार कभी न जाए।
- चैनल और प्रदाता अलग-अलग विफल हों: एसएमएस प्रदाता की गड़बड़ी से पुश में देरी न हो।
संख्याएं: सामान्य दिन की ५ करोड़ सूचनाएं औसतन लगभग ६०० प्रति सेकंड हैं, लेकिन सुबह ९ बजे ३ करोड़ उपयोगकर्ताओं को तय किया गया मार्केटिंग अभियान कुछ देर के लिए दसियों हजार प्रति सेकंड मांग सकता है। झटके के लिए डिजाइन करें, और उसे अलग रखें।
आर्किटेक्चर
- भेजने वाली सेवाएं (ऑर्डर सेवा, मार्केटिंग अभियान, सुरक्षा चेतावनी)। एक ही एपीआई को घटना का प्रकार, प्राप्तकर्ता और डेटा भेजती हैं। वे कभी सीधे एपीएनएस या ट्विलियो से बात नहीं करतीं।
- सूचना एपीआई (दोहराव रोकने वाली कुंजी)। अनुरोध जांचती है, कुंजी (जैसे
order-8812:shipped) से दोहराव ठुकराती है, प्राथमिकता वर्ग तय करती है और कौन से चैनल लागू हैं यह तय करती है। - पसंद और संपर्क। हर श्रेणी और चैनल की सहमति, सदस्यता छोड़ना, शांत घंटे और समय क्षेत्र, साथ में डिवाइस टोकन, जांचे गए ईमेल पते और फोन नंबर। कानूनी रूप से जरूरी सदस्यता छोड़ना (मार्केटिंग ईमेल, एसएमएस) यहीं, हर बार जांचा जाता है।
- चैनल कतारें (पुश, ईमेल, एसएमएस)। हर चैनल की एक कतार, और व्यवहार में हर चैनल की ऊंची प्राथमिकता और थोक की अलग कतारें, ताकि कोई अभियान पासवर्ड रीसेट के आगे न बैठे।
- भेजने वाले वर्कर (पुश, ईमेल, एसएमएस)। काम उठाते हैं, टेम्पलेट भरते हैं, प्रदाता को बुलाते हैं, नतीजा दर्ज करते हैं और नीचे वाली दोबारा कोशिश की नीति लागू करते हैं।
- टेम्पलेट (कई भाषाएं)। हर सूचना प्रकार और भाषा के संस्करण वाले टेम्पलेट। भेजते समय भरे जाते हैं, इसलिए सुधारी गई गलती कतार में बैठे संदेशों पर भी लागू होती है।
- प्रदाता (एपीएनएस / एफसीएम, ईमेल प्रदाता, एसएमएस गेटवे)। अपनी सीमाओं, त्रुटि कोड और गड़बड़ियों वाले बाहरी सिस्टम। हर एक को एडेप्टर में लपेटें ताकि विफलता पर दूसरा प्रदाता जोड़ सकें।
- डिलीवरी लॉग। हर कोशिश और प्रदाता की हर रसीद या वेबहुक (पहुंचा, लौटा, खोला, सदस्यता छोड़ी) यहां आती है। सहायता टीम लॉग खंगाले बिना बता सकती है "क्या उसे कोड मिला?"
एक घटना शुरू से अंत तक: "ऑर्डर भेजा गया"
१. ऑर्डर सेवा POST /notifications को type=order_shipped, user_id=42, ट्रैकिंग डेटा और idempotency_key=order-8812:shipped के साथ बुलाती है।
२. एपीआई कुंजी जांचती है। अगर पिछले कुछ दिनों में दिखी थी, तो मूल नतीजा लौटाती है। ऑर्डर सेवा की दोबारा कोशिशें अब नुकसानदेह नहीं।
३. पसंद बताती है कि उपयोगकर्ता ४२ को शिपिंग अपडेट पुश और ईमेल से चाहिए, एसएमएस से नहीं। उसके समय क्षेत्र में रात के २ बजे हैं, लेकिन शिपिंग अपडेट शांत घंटों में "चुपचाप" पुश के रूप में जा सकते हैं।
४. एपीआई एक पुश और एक ईमेल काम कतार में डालती है, दोनों ऊंची प्राथमिकता के, दोनों में वही कुंजी।
५. पुश वर्कर स्थानीय भाषा का टेम्पलेट भरकर एपीएनएस या एफसीएम से हर सक्रिय डिवाइस टोकन पर भेजता है और जवाब दर्ज करता है। ईमेल वर्कर एचटीएमएल टेम्पलेट भरकर ईमेल प्रदाता को सौंपता है।
६. बाद में प्रदाता के वेबहुक ईमेल के लिए "पहुंचा" बताते हैं और ऐप की अपनी रसीद पुश के लिए "दिखाया गया"। डिलीवरी लॉग में पूरा इतिहास है।
दोबारा कोशिश, मृत संदेश और ठीक एक बार का भ्रम
वितरित सिस्टम कम से कम एक बार पहुंचाते हैं। तरकीब यह है कि उपयोगकर्ता को यह ठीक एक बार लगे:
- त्रुटियां वर्गीकृत करें। दर सीमा (४२९), सर्वर त्रुटियों (५०० श्रेणी) और समय खत्म होने पर दोबारा कोशिश करें। स्थायी त्रुटियों पर नहीं: अमान्य हो चुके टोकन के लिए एपीएनएस
410 Unregisteredलौटाता है, और ईमेल प्रदाता स्थायी वापसी बताते हैं। इन पर दोबारा कोशिश सिर्फ भेजने वाले के रूप में आपकी साख बिगाड़ती है। - बेतरतीब फर्क के साथ अंतराल। १ सेकंड, २ सेकंड, ४ सेकंड, थोड़ी बेतरतीबी और ऊपरी सीमा के साथ। इसके बिना हर विफल काम एक ही पल में दोबारा कोशिश करता है और पहले से परेशान प्रदाता पर टूट पड़ता है।
- सीमित कोशिशें, फिर मृत संदेश कतार। सीमा के बाद काम को त्रुटि के साथ मृत संदेश कतार में भेजें। किसी इंसान या तंत्र को उस कतार को देखना होगा; न पढ़ी जाने वाली कतार संदेश खोने का बस धीमा तरीका है।
- हर कोशिश पर वही कुंजी। वर्कर भेजने से पहले डिलीवरी लॉग देखता है, और कई प्रदाता भी ऐसी कुंजी स्वीकार करते हैं। तब "प्रदाता ने स्वीकार किया" और "हमने दर्ज किया" के बीच गिरने से भी दोहराव नहीं होता।
- सफाई करें। मृत पुश टोकन तुरंत हटाएं और स्थायी रूप से लौटे ईमेल रोक दें, वरना उस उपयोगकर्ता को हर भविष्य की सूचना एक कोशिश बर्बाद करेगी।
हर चैनल की असलियत
| चैनल | लागत | देरी | सावधानियां |
|---|---|---|---|
| पुश (एपीएनएस, एफसीएम) | लगभग मुफ्त | सेकंड | टोकन बदलते और खत्म होते हैं; सामग्री की सीमा लगभग ४ केबी; ऑपरेटिंग सिस्टम कम प्राथमिकता वाले पुश धीमे या गायब कर सकता है; गूगल ने २०२४ में एफसीएम के पुराने एपीआई बंद कर नया संस्करण अपनाया |
| ईमेल | पैसे का छोटा अंश | सेकंड से मिनट | पहुंच साख पर टिकी है: एसपीएफ, डीकेआईएम और डीमार्क जरूरी हैं; २०२४ से जीमेल और याहू थोक भेजने वालों से एक क्लिक में सदस्यता छोड़ने और कम स्पैम शिकायत दर की मांग करते हैं |
| एसएमएस | हर संदेश के कुछ पैसे, देश के हिसाब से | सेकंड | बड़े पैमाने पर महंगा; वाहक पंजीकरण (अमेरिका में १०डीएलसी) और सहमति के नियम; भेजने वाले की पहचान देश के हिसाब से अलग |
| ऐप के अंदर | मुफ्त | ऑनलाइन हो तो तुरंत | सिर्फ ऐप खुला रहने पर; अक्सर इनबॉक्स की तरह रखा और मिलाया जाता है |
लागत वाला कॉलम रूटिंग नीति तय करता है। ओटीपी कोड एक एसएमएस के लायक हो सकता है। "आपके दोस्त ने पोस्ट किया" नहीं।
उपयोगकर्ताओं को अपनी ही कंपनी से बचाना
सबसे कठिन जरूरतें तकनीकी नहीं हैं:
- आवृत्ति की सीमा। हर उपयोगकर्ता को रोज एन से ज्यादा मार्केटिंग पुश नहीं, केंद्र से लागू, चाहे कितनी भी टीमें भेजना चाहें।
- शांत घंटे उपयोगकर्ता के समय क्षेत्र में, सुरक्षा और लेनदेन वाले संदेशों के लिए साफ छूट के साथ।
- समेटना और सार। पांच मिनट में दस पसंद एक सूचना बननी चाहिए, दस नहीं। पुश प्रदाता समेटने वाली कुंजियां देते हैं; आपके मंच में समूह बनाने की समय खिड़कियां होनी चाहिए।
- एक बार सदस्यता छोड़ी, मतलब छोड़ी। पसंद स्टोर ही इकलौता सच्चा स्रोत है, और हर चैनल उसे भेजते समय जांचता है, अभियान तय करते समय नहीं।
अहम मेट्रिक्स
| मेट्रिक | क्यों |
|---|---|
| घटना से प्रदाता की स्वीकृति तक का समय, प्राथमिकता के हिसाब से | दिखाता है कि थोक ट्रैफिक लेनदेन वाले संदेशों को देरी करा रहा है या नहीं |
| कोड के हिसाब से प्रदाता की त्रुटि दर | आपके बग (४०० श्रेणी) को उनकी गड़बड़ी (५०० श्रेणी) से अलग करती है |
| मृत संदेश कतार की गहराई और उम्र | वे संदेश जिन्हें आप चुपचाप नहीं पहुंचा पाए |
| अमान्य टोकन और स्थायी वापसी दर | संपर्क डेटा की सफाई |
| हर अभियान के बाद सदस्यता छोड़ने की दर | इसका इकलौता ईमानदार पैमाना कि लोग आपका भेजा चाहते हैं या नहीं |
उत्पादन जांच सूची
- सभी भेजने वाली सेवाओं के लिए एक एपीआई; कहीं और प्रदाता से सीधा जुड़ाव नहीं
- हर अनुरोध पर दोहराव रोकने वाली कुंजी जरूरी और हर दोबारा कोशिश पर वही
- पसंद, सदस्यता छोड़ना और शांत घंटे भेजते समय जांचे जाते हैं
- हर चैनल की ऊंची प्राथमिकता और थोक की अलग कतारें
- दोबारा कोशिश का वर्गीकरण, बेतरतीब अंतराल, कोशिशों की सीमा और निगरानी वाली मृत संदेश कतार
- अमान्य टोकन और स्थायी वापसी अपने आप हटते हैं
- ईमेल के लिए एसपीएफ, डीकेआईएम, डीमार्क और एक क्लिक में सदस्यता छोड़ना
- शोर वाली घटनाओं के लिए आवृत्ति सीमा और समेटना या सार
- सहायता टीम के लिए डिलीवरी लॉग, प्रदाता की रसीदों के साथ
- अहम चैनलों के लिए दूसरा प्रदाता तैयार
जो बचा रह गया
सबसे अच्छा सूचना सिस्टम वह है जिस पर उपयोगकर्ता का ध्यान मुश्किल से जाए: कोड तब आए जब मांगा, पैकेज की खबर तब आए जब पैकेज चले, और रात ३ बजे ऐसा कुछ न आए जो रुक सकता था।
यह संयम एक डिजाइन फैसला है, डिफॉल्ट नहीं। हर टीम जो कोई सुविधा लाएगी, उसके लिए एक सूचना चाहेगी। मंच वह जगह है जहां कोई कह सकता है "इसे रोज के सार में डाल दो," और सही हो।
स्रोत
- एप्पल: एपीएनएस को सूचना अनुरोध भेजना (४१० सहित स्थिति कोड)
- फायरबेस क्लाउड मैसेजिंग: पुराने एपीआई से नए संस्करण पर जाना
- गूगल: ईमेल भेजने वालों के दिशानिर्देश (थोक भेजने वालों की जरूरतें)
- आरएफसी ८०५८: सूची ईमेल हेडर में एक क्लिक की सुविधा
- एडब्ल्यूएस आर्किटेक्चर ब्लॉग: बढ़ता अंतराल और बेतरतीब फर्क
- इसी श्रृंखला में: चैट सिस्टम डिजाइन करें, रेट लिमिटर डिजाइन करें, घटना आधारित आर्किटेक्चर