कोई प्रदाता आपका मासिक वॉल्यूम स्वीकार कर सकता है, फिर भी चेकआउट रुकने के बाद आने वाले अचानक उछाल को धीमा कर सकता है। भेजने के अनुबंध की तुलना उस काम से करें जिसे आपके एप्लिकेशन को रिकवर करना होगा।
अगर आपको ट्रांज़ैक्शनल ईमेल भेजने के साथ थ्रेड और जवाबों वाले मेलबॉक्स चाहिए, तो Bird चुनें। अगर आपका AWS एप्लिकेशन sesv2 भेजने के कमांड पर बना है, तो Amazon SES बेहतर विकल्प है।
ट्रांज़ैक्शनल ईमेल क्या है?
ट्रांज़ैक्शनल ईमेल प्राप्तकर्ता के किसी लेन-देन या खाता गतिविधि से जुड़ा होता है, जैसे रसीद या पासवर्ड रीसेट। संदेश का उद्देश्य उसकी श्रेणी तय करता है। प्राप्तकर्ताओं की संख्या या अपने आप भेजा जाना प्रचार सामग्री को ट्रांज़ैक्शनल नहीं बनाता।
आपको किन बातों का मूल्यांकन करना चाहिए?
अपने एप्लिकेशन के लिए ज़रूरी क्षमताओं की तुलना करें, फिर तय करने से पहले विफलता की स्थितियों का परीक्षण करें।
- डिलीवरेबिलिटी और प्रतिष्ठा के टूल। क्या आप अपने डोमेन को SPF, DKIM और DMARC से आसानी से प्रमाणित कर सकते हैं? ज़रूरत पड़ने पर क्या डेडिकेटेड IP उपलब्ध हैं, और क्या उन्हें वार्म अप करने के लिए मार्गदर्शन मिलता है?
- API और SDK की गुणवत्ता। क्या API अच्छी तरह प्रलेखित है, और क्या आपकी इस्तेमाल की जाने वाली भाषाओं में आधिकारिक SDK उपलब्ध हैं?
- SMTP और HTTP दोनों। जाँचें कि आपका रनटाइम कौन-सा सबमिशन इंटरफ़ेस सपोर्ट करता है। मौजूदा SMTP क्लाइंट रिले का उपयोग कर सकते हैं; संरचित अनुरोध भेजने वाले एप्लिकेशन के लिए HTTP API उपयुक्त है।
- टेम्पलेट। वेरिएबल प्रतिस्थापन वाले सर्वर-साइड टेम्पलेट से आप डिप्लॉय किए बिना कॉपी बदल सकते हैं और सभी संदेशों में फ़ॉर्मेटिंग एक जैसी रख सकते हैं।
- वेबहुक और इवेंट। डिलीवरी, ओपन, क्लिक, बाउंस और शिकायत के रीयल-टाइम वेबहुक इवेंट से आप अपने रिकॉर्ड सटीक रखते हैं और आगे का लॉजिक ट्रिगर करते हैं।
- एनालिटिक्स। डिलीवरी, बाउंस और एंगेजमेंट दरों के समेकित दृश्य, और किसी एक संदेश की जाँच के लिए खोजने योग्य लॉग।
- सप्रेशन प्रबंधन। प्रदाता को हार्ड बाउंस और शिकायतों को अपने-आप सप्रेस करना चाहिए, ताकि आपका एप्लिकेशन उन संकेतों से अवरुद्ध भेजना रोक सके। पूछें कि सप्रेशन सूचियाँ कैसे प्रबंधित होती हैं और क्या आप उन्हें देख सकते हैं।
- स्केलेबिलिटी। क्या यह आपकी अधिकतम वॉल्यूम (प्रोडक्ट लॉन्च, छुट्टियों का उछाल) को बिना मैन्युअल हस्तक्षेप या अप्रत्याशित थ्रॉटलिंग के संभाल लेगा?
- कीमत। मॉडल (प्रति संदेश, स्तरीय, शामिल वॉल्यूम) समझें और जानें कि ओवरेज कहाँ से शुरू होता है। अपनी अपेक्षित वॉल्यूम और पीक अवधियों के लिए इसकी गणना करें।
- सहायता। रात 2 बजे मेल रुक जाए, तो आप किसी व्यक्ति तक कैसे पहुँचेंगे, और वे कितनी जल्दी जवाब देंगे? जो प्लान आप वास्तव में खरीदेंगे, उसके साथ मिलने वाला सहायता स्तर जाँचें।
- अनुपालन। प्रतिबद्ध होने से पहले पुष्टि करें कि प्रदाता आपके व्यवसाय पर लागू डेटा-प्रबंधन और क्षेत्रीय आवश्यकताओं को पूरा करता है।
SMTP रिले सेवा कब चुननी चाहिए?
जब आपका एप्लिकेशन पहले से ईमेल संदेश बनाता है और कॉन्फ़िगर करने योग्य मेल सर्वर का समर्थन करता है, तब SMTP रिले चुनें। जब आपको संरचित अनुरोध फ़ील्ड या संग्रहीत टेम्पलेट चाहिए, तब HTTP API चुनें।
Bird के लिए इंटरफ़ेस चुनने से पहले सबमिशन और रिकवरी के तरीकों की तुलना करें:
| निर्णय या विफलता | SMTP रिले | HTTP ईमेल API |
|---|---|---|
| प्रमाणीकरण | यूज़रनेम bird, पासवर्ड के रूप में API कुंजी, emails स्कोप के साथ। क्षेत्रीय SMTP होस्ट पर TLS का उपयोग करें। | Authorization: Bearer हेडर में API कुंजी, emails स्कोप के साथ। |
| सबमिशन का जवाब | अंतिम 250 में कतार में रखे गए संदेश की ID होती है। इसे एप्लिकेशन इवेंट के साथ सहेजें। | 202 में स्वीकार किए गए संदेश की ID होती है। इसे एप्लिकेशन इवेंट के साथ सहेजें। |
| फिर से प्रयास की ज़िम्मेदारी | सबमिशन को फिर से प्रयास करने का काम आपका एप्लिकेशन या SMTP क्लाइंट करता है। एक ही तार्किक संदेश के लिए X-Bird-Idempotency-Key का दोबारा उपयोग करें। | सबमिशन को फिर से प्रयास करने का काम आपका एप्लिकेशन या SDK करता है। एक ही तार्किक संदेश के लिए Idempotency-Key का दोबारा उपयोग करें। |
| समाप्ति | किसी न भेजे गए जॉब को फिर से प्रयास करने से पहले आपका ऐप्लिकेशन जाँचता है कि उसका लिंक या कोड अभी भी मान्य है या नहीं। | दूसरा अनुरोध सबमिट करने से पहले यही जाँच लागू करें। |
| थ्रूपुट से जुड़ी मान्यताएँ | एक साथ खुले कनेक्शनों की सीमाएँ भेजने के कोटा से अलग जाँचें। ज़्यादा खुले कनेक्शन होने से भेजने की दर की अनुमति तय नहीं होती। | प्रतिक्रिया के रेट-लिमिट हेडर के आधार पर API अनुरोधों की गति तय करें। अनुरोध दर और प्राप्तकर्ताओं की संख्या अलग-अलग मात्राएँ हैं। |
| इवेंट से मिलने वाला प्रमाण | कतार में डाले जाने के जवाब के बाद प्राप्तकर्ता इवेंट पर नज़र रखें। स्थगित डिलीवरी के लिए Bird फिर से प्रयास करता है। | स्वीकृति के बाद उन्हीं प्राप्तकर्ता इवेंट पर नज़र रखें। स्थगित डिलीवरी के लिए Bird फिर से प्रयास करता है। |
| पूल का चयन | API कुंजी का SMTP कॉन्फ़िगरेशन पूल चुनता है। बिना कॉन्फ़िगरेशन वाली कुंजी संगठन के डिफ़ॉल्ट पूल का उपयोग करती है। | हर भेजने पर ip_pool_id सेट करें, या संगठन के डिफ़ॉल्ट पूल का उपयोग करें। |
SMTP रिले गाइड कनेक्शन सेटिंग और जवाबों को संभालने का तरीका बताती है। HTTP सेंड संदर्भ API अनुरोध और प्रतिक्रिया को परिभाषित करता है। दोनों इंटरफ़ेस एक ही ईमेल पाइपलाइन का उपयोग करते हैं, जिसमें सप्रेशन को संभालना और साइनिंग शामिल हैं।
ट्रांसपोर्ट स्वीकृति का अर्थ है कि Bird ने संदेश को कतार में डाल दिया है। बाद में आने वाला email.delivered इवेंट बताता है कि प्राप्त करने वाले सर्वर ने उसे स्वीकार कर लिया। इनमें से कोई भी इनबॉक्स में पहुँचने या पढ़े जाने की पुष्टि नहीं करता।
अपना भेजने का रिकॉर्ड idempotency रिटेंशन अवधि के बाद भी रखें, क्योंकि बाद का फिर से प्रयास एक और संदेश बना सकता है। स्थगित डिलीवरी के लिए Bird पहले से फिर से प्रयास कर रहा होता है; नया भेजना बनाने से वह काम दोहराया जाता है जो अभी चल रहा है।
दोनों इंटरफ़ेस के लिए समर्पित IP वैकल्पिक हैं। किसी बर्स्ट को समर्पित पूल से भेजने से पहले पूल और वार्मअप की आवश्यकताएँ जाँचें।
आपको कौन-सी प्रकाशित क्षमताओं की तुलना करनी चाहिए?
हर फ़ीचर के पीछे का प्रलेखित इंटरफ़ेस जाँचें। पार्स किया गया ईमेल प्राप्त करना, उसकी सामग्री संग्रहीत करना और बातचीत का API उपलब्ध कराना अलग-अलग क्षमताएँ हैं।
| प्रदाता | सबमिशन | प्राप्तकर्ता से जुड़े प्रमाण | प्राप्त करने और भेजने का इन्फ्रास्ट्रक्चर |
|---|---|---|---|
| Bird | HTTP भेजना और SMTP | इवेंट, संदेश लॉग और सप्रेशन | मेलबॉक्स और थ्रेड; डेडिकेटेड IP पूल |
| Amazon SES | SendEmail API और SMTP | इवेंट डेस्टिनेशन और खाता सप्रेशन सूची | समर्थित क्षेत्रों में रसीद नियम; स्टैंडर्ड या प्रबंधित डेडिकेटेड IP |
| SendGrid | Mail Send API और SMTP | Event Webhook और Email Activity | Inbound Parse webhook; IP पूल |
| Mailgun | Messages API और SMTP | डिलीवरी इवेंट और बाउंस रिकॉर्ड | मेल फ़ॉरवर्ड या संग्रहीत करने के लिए रूट; IP पूल |
| Postmark | Email API और SMTP | वेबहुक और स्ट्रीम सप्रेशन | इनबाउंड वेबहुक; डेडिकेटेड IP की पात्रता |
| Resend | Email API और SMTP | वेबहुक इवेंट और API लॉग | प्राप्त सामग्री और जवाब; प्रबंधित डेडिकेटेड IP |
जो प्लान आप खरीदेंगे, उसके लिए पात्रता और डेटा रखे जाने की अवधि की पुष्टि करें। किसी फ़ीचर का लिंक होने से यह तय नहीं होता कि कितना थ्रूपुट मिलेगा या रिकवरी कितने समय में होगी।
संग्रहीत सामग्री के लिए जाँचें कि कौन-से बॉडी, हेडर, अटैचमेंट और इवेंट रिकॉर्ड बाद में प्राप्त किए जा सकते हैं। डेटा रेज़िडेंसी के लिए प्रकाशित संग्रहण और प्रोसेसिंग का दायरा अपवादों सहित प्राप्त करें। केवल क्षेत्रीय एंडपॉइंट होने से यह अनुबंध स्थापित नहीं होता।
हर महीने एक करोड़ ईमेल भेजने पर क्या बदलता है?
आवश्यक भेजने की दर पीक ट्रैफ़िक और रिकवरी क्षमता से तय होती है। केवल मासिक वॉल्यूम से यह तय नहीं होती।
30 दिनों के एक उदाहरण महीने में एक-एक प्राप्तकर्ता वाले एक करोड़ संदेशों का औसत लगभग 3.86 संदेश प्रति सेकंड होता है। दस मिनट में 1,00,000 संदेशों के बर्स्ट के लिए लगभग 167 संदेश प्रति सेकंड चाहिए। बर्स्ट का मूल्यांकन मासिक सीमा से अलग करें।
यदि 100 नए संदेश प्रति सेकंड की दर पर दस मिनट का व्यवधान आता है, तो आपके एप्लिकेशन में 60,000 बिना भेजे गए जॉब जमा हो जाते हैं। यदि नया काम 100 प्रति सेकंड पर आता रहे, तो उस बैकलॉग को बीस मिनट में खाली करने के लिए 50 प्रति सेकंड और चाहिए। इसलिए रिकवरी का लक्ष्य 150 स्वीकृत संदेश प्रति सेकंड है, जिसमें फिर से प्रयास या प्राप्त करने वाले सर्वर की देरी शामिल नहीं है।
जाँचें कि हर प्रदाता काम की गिनती कैसे करता है। SES कोटा प्राप्तकर्ताओं की गिनती करते हैं और हर क्षेत्र में अलग-अलग लागू होते हैं। इनमें एक रोलिंग दैनिक कोटा और एक स्वीकृति दर शामिल है। SES यह चेतावनी भी देता है कि वास्तविक स्वीकृति खाते की अधिकतम दर से कम हो सकती है।
Resend की सीमाएँ API अनुरोध दर को ईमेल वॉल्यूम कोटा से अलग रखती हैं। Bird के अनुरोध दर सीमा हेडर प्रभावी अनुरोध कोटा बताते हैं। इनमें से किसी की भी तुलना परिदृश्य की प्राप्तकर्ता दर से करने से पहले अपने बैच साइज़ को अनुरोधों की संख्या में बदलें।
घटना के बाद रिकवरी का परीक्षण कैसे करें?
परीक्षण करें कि सबमिशन विफल होने या webhook हैंडलर के अनुपलब्ध होने के बाद आपका एप्लिकेशन काम कैसे फिर शुरू करता है। प्रदाता का स्टेटस पेज घटना का संदर्भ देता है; कौन-सा काम बाकी है, यह आपके संदेश रिकॉर्ड से पता चलता है।
| प्रदाता | प्रकाशित सीमा या त्रुटि अनुबंध | आधिकारिक स्टेटस |
|---|---|---|
| Bird | प्रभावी कोटा और फिर से प्रयास के हेडर | Bird स्थिति |
| Amazon SES | भेजने का कोटा | AWS सेवा स्थिति |
| SendGrid | API दर सीमाएँ | SendGrid स्थिति |
| Mailgun | API त्रुटि और दर-सीमा अनुबंध | Mailgun स्थिति |
| Postmark | API प्रतिक्रिया और त्रुटि अनुबंध | Postmark स्थिति |
| Resend | उपयोग सीमाएँ | Resend स्थिति |
एक टेस्ट वर्कर को रोकें, जॉब जमा होने दें और खाते की प्रभावी सीमा के भीतर फिर से शुरू करें। मापें कि सबसे पुराना योग्य जॉब कितनी देर प्रतीक्षा करता है। समाप्त हो चुके रीसेट जॉब को अपने-आप दोबारा चलाने के बजाय नया अनुरोध करने का रास्ता चाहिए।
रिकवरी के दौरान हर बिज़नेस-इवेंट पहचानकर्ता को सुरक्षित रखें। किसी अनिश्चित सबमिशन के लिए फिर से प्रयास करने से पहले प्रोवाइडर का डुप्लिकेट-भेजने से जुड़ा अनुबंध जाँचें। Postmark किसी idempotency कुंजी सुविधा का दस्तावेज़ नहीं देता, इसलिए उसके इंटीग्रेशन में एप्लिकेशन के स्तर पर सुरक्षा उपाय चाहिए। Bird में पूरी हो चुकी प्रतिक्रियाओं को रखने की अवधि तीन घंटे है। उस अवधि के बाद रिकवरी के लिए आपका अपना इवेंट रिकॉर्ड चाहिए।
बाद में आने वाले प्राप्तकर्ता इवेंट को सहेजे गए मैसेज ID से मिलाएँ। प्राप्त करने वाले सर्वर के स्वीकार करने से यह तय नहीं होता कि ईमेल इनबॉक्स में पहुँचा या पढ़ा गया। ट्रांज़ैक्शनल API जीवनचक्र इन अलग-अलग परिणामों को समझाता है।
कीमत की तुलना में क्या शामिल होना चाहिए?
आप जो प्लान, बिलिंग अवधि और मुद्रा खरीदेंगे, ठीक उसी के लिए प्रकाशित समावेशों की तुलना करें। भेजने की मात्रा को उसके लिए ज़रूरी इंफ्रास्ट्रक्चर और डेटा रखने की अवधि से अलग रखें।
| प्रोवाइडर की कीमत का स्रोत | आपके वर्कलोड के लिए जाँचने योग्य समावेश |
|---|---|
| Bird कीमतें | भेजने की सीमा, सीमा से अधिक उपयोग का शुल्क, समर्पित इन्फ्रास्ट्रक्चर, सहेजी गई सामग्री और सपोर्ट |
| Amazon SES की कीमतें | आउटबाउंड और इनबाउंड उपयोग, डेटा शुल्क, समर्पित IP और वैकल्पिक सुविधाएँ |
| SendGrid की कीमतें | प्लान की मात्रा, सीमा से अधिक उपयोग का शुल्क, समर्पित IP की पात्रता, गतिविधि डेटा की अवधि और सपोर्ट |
| Mailgun की कीमतें | भेजने की मात्रा, लॉग और संदेश सहेजने की अवधि, समर्पित IP और सपोर्ट |
| Postmark की कीमतें | भेजने की सीमा, अतिरिक्त मात्रा, डेटा सहेजने के विकल्प और समर्पित IP की पात्रता |
| Resend की कीमतें | भेजने और प्राप्त करने की सीमाएँ, सीमा से अधिक उपयोग का शुल्क, डेटा सहेजने की अवधि और समर्पित IP की पात्रता |
जाँचें कि बताई गई सीमा अनुरोधों, संदेशों या प्राप्तकर्ताओं में से किसे गिनती है। जो सुविधाएँ शामिल नहीं हैं, उन्हें शामिल मानने के बजाय प्लान के साथ दर्ज करें। अलग-अलग प्रोडक्ट की तुलना Bird की प्रोवाइडर तुलनाओं में दी गई है।
अक्सर पूछे जाने वाले प्रश्न
ट्रांजैक्शनल और मार्केटिंग ईमेल में क्या अंतर है?
ट्रांजैक्शनल मेल किसी लेनदेन या खाता गतिविधि से जुड़ा होता है। मार्केटिंग मेल किसी चीज़ का प्रचार करता है या सब्सक्राइब की गई सामग्री पहुँचाता है। यह अंतर संदेश के उद्देश्य से तय होता है, तब भी जब दोनों स्वचालित हों।
क्या एक ही प्रदाता ट्रांजैक्शनल और मार्केटिंग दोनों तरह का मेल संभाल सकता है?
एक प्रदाता दोनों वर्कफ़्लो संभाल सकता है। श्रेणी नीति, प्रमाणित भेजने वाली पहचानों और IP पूल के चयन की अलग-अलग जाँच करें। साझा इंफ्रास्ट्रक्चर में मार्केटिंग ट्रैफ़िक की प्रतिष्ठा संबंधी समस्याएँ फिर भी ऑपरेशनल मेल को प्रभावित कर सकती हैं।
क्या मुझे डेडिकेटेड IP की ज़रूरत है?
शुरुआत में नहीं। कम वॉल्यूम पर साझा IP पूल पर्याप्त होते हैं और आपको IP वार्मअप से बचाते हैं। डेडिकेटेड IP तब उपयोगी होता है जब आपका वॉल्यूम इतना अधिक और स्थिर हो कि वह अपनी प्रतिष्ठा बनाए रख सके। ऐसा प्रदाता चुनें जो आपको साझा IP से शुरू करने दे और आँकड़े उचित ठहराएँ तब डेडिकेटेड पर जाने दे।
Bird की भूमिका
आप SMTP या HTTP API के ज़रिए संदेश भेज सकते हैं। दोबारा उपयोग होने वाली सामग्री के लिए टेम्पलेट प्रकाशित करें। प्राप्तकर्ता इवेंट्स को सब्सक्राइब करें। अलग-अलग संदेशों की जाँच ईमेल लॉग में करें।
IP पूल का चयन संदेश की श्रेणी से अलग करें। भेजने का वॉल्यूम बदलते समय वार्मअप मार्गदर्शन का पालन करें। डुप्लिकेट संदेशों की हैंडलिंग और रिकवरी की जाँच के लिए ऑपरेशनल चेकलिस्ट का उपयोग करें।
अंतिम चुनाव कैसे करें?
- दस्तावेज़ित इंटरफ़ेस और प्राप्तकर्ता नियंत्रणों को अपने एप्लिकेशन की ज़रूरतों से मिलाएँ।
- पीक ट्रैफ़िक और बैकलॉग रिकवरी, दोनों के लिए प्रभावी कोटा की पुष्टि करें।
- सहेजे गए मैसेज रिकॉर्ड और बिज़नेस-इवेंट रिकॉर्ड के आधार पर विफलता से निपटने की प्रक्रिया का परीक्षण करें।
- जो प्लान आप खरीदेंगे, उसमें प्रकाशित रूप से शामिल सुविधाओं, रिटेंशन और सपोर्ट की तुलना करें।