कोई प्रोवाइडर आपकी मासिक मात्रा स्वीकार कर सकता है, लेकिन चेकआउट आउटेज के बाद बर्स्ट को थ्रॉटल कर सकता है। भेजने के कॉन्ट्रैक्ट की तुलना उस काम से करें जो आपके एप्लिकेशन को रिकवर करना होगा।
ट्रांज़ैक्शनल ईमेल क्या है?
ट्रांज़ैक्शनल ईमेल प्राप्तकर्ता के लेन-देन या अकाउंट गतिविधि की सेवा करता है, जैसे रसीद या पासवर्ड रीसेट। संदेश का उद्देश्य उसकी श्रेणी निर्धारित करता है। प्राप्तकर्ता की संख्या और स्वचालित ट्रिगरिंग प्रमोशनल कंटेंट को ट्रांज़ैक्शनल नहीं बनाती।
आपको किन बातों का मूल्यांकन करना चाहिए?
अपने एप्लिकेशन की ज़रूरी क्षमताओं की तुलना करें, फिर कमिट करने से पहले विफलता पथों का परीक्षण करें।
- डिलीवरेबिलिटी और रेप्युटेशन टूलिंग। क्या आप अपने डोमेन को SPF, DKIM, और DMARC से आसानी से प्रमाणित कर सकते हैं? क्या ज़रूरत पड़ने पर डेडिकेटेड IP उपलब्ध हैं, और उन्हें वार्म अप करने के लिए मार्गदर्शन है?
- API और SDK गुणवत्ता। क्या API अच्छी तरह डॉक्यूमेंटेड है, और आपकी भाषाओं में आधिकारिक SDK उपलब्ध हैं?
- SMTP और HTTP दोनों। जाँचें कि आपका रनटाइम कौन सा सबमिशन इंटरफ़ेस सपोर्ट करता है। मौजूदा SMTP क्लाइंट रिले का उपयोग कर सकते हैं; HTTP API उन एप्लिकेशनों की सेवा करता है जो स्ट्रक्चर्ड रिक्वेस्ट सबमिट करते हैं।
- टेम्पलेट। वेरिएबल सब्स्टिट्यूशन वाले सर्वर-साइड टेम्पलेट आपको डिप्लॉय किए बिना कॉपी बदलने और सभी संदेशों में फ़ॉर्मेटिंग एकसमान रखने की सुविधा देते हैं।
- Webhooks और इवेंट। डिलीवरी, ओपन, क्लिक, बाउंस, और कंप्लेंट के लिए रियल-टाइम webhook इवेंट आपके रिकॉर्ड सटीक रखने और फ़ॉलो-अप लॉजिक ट्रिगर करने का तरीका हैं।
- एनालिटिक्स। डिलीवरी, बाउंस और एंगेजमेंट दरों के एग्रीगेट व्यू, साथ ही किसी व्यक्तिगत संदेश की जाँच के लिए सर्च करने योग्य लॉग।
- सप्रेशन हैंडलिंग। प्रोवाइडर को हार्ड बाउंस और कंप्लेंट को स्वचालित रूप से सप्रेस करना चाहिए ताकि आपका एप्लिकेशन उन सिग्नलों से ब्लॉक हुए भेजने बंद कर सके। पूछें कि सप्रेशन सूचियाँ कैसे प्रबंधित होती हैं और क्या आप उनका निरीक्षण कर सकते हैं।
- स्केलेबिलिटी। क्या यह आपके पीक वॉल्यूम (प्रोडक्ट लॉन्च, हॉलिडे स्पाइक) को मैनुअल हस्तक्षेप या अचानक थ्रॉटलिंग के बिना संभाल सकता है?
- प्राइसिंग। मॉडल (प्रति-संदेश, टियर्ड, शामिल वॉल्यूम) और ओवरेज कहाँ शुरू होता है, यह समझें। अपने अपेक्षित वॉल्यूम और पीक अवधियों के लिए इसकी गणना करें।
- सपोर्ट। जब रात 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 इवेंट का मतलब है कि प्राप्तकर्ता सर्वर ने इसे स्वीकार किया। दोनों में से कोई भी इनबॉक्स प्लेसमेंट या पठन स्थापित नहीं करता।
अपना भेजने का रिकॉर्ड आइडेम्पोटेंसी रिटेंशन विंडो के बाद भी रखें, क्योंकि बाद का फिर से प्रयास एक और संदेश बना सकता है। डिफ़रल को 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 | Webhooks और स्ट्रीम सप्रेशन | इनबाउंड webhook; डेडिकेटेड IP पात्रता |
| Resend | Email API और SMTP | Webhook इवेंट और 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 के दस्तावेज़ बताते हैं कि आइडेम्पोटेंसी-की फ़ीचर उपलब्ध नहीं है, इसलिए इसके इंटीग्रेशन को एप्लिकेशन सुरक्षा उपायों की ज़रूरत है। Bird की पूर्ण-रिस्पॉन्स रिटेंशन तीन घंटे है। उस विंडो के बाद रिकवरी के लिए आपके अपने इवेंट रिकॉर्ड की ज़रूरत है।
बाद के प्राप्तकर्ता इवेंट को सेव किए गए मैसेज ID से मैच करें। प्राप्तकर्ता-सर्वर की स्वीकृति इनबॉक्स प्लेसमेंट या पठन स्थापित नहीं करती। ट्रांज़ैक्शनल API लाइफ़साइकल इन अलग-अलग परिणामों की व्याख्या करता है।
मूल्य तुलना में क्या शामिल होना चाहिए?
जो सटीक प्लान, बिलिंग अवधि और मुद्रा आप खरीदेंगे, उसके लिए प्रकाशित शामिल चीज़ों की तुलना करें। भेजने की मात्रा को उसके लिए आवश्यक इंफ़्रास्ट्रक्चर और रिटेंशन से अलग रखें।
| प्रोवाइडर प्राइसिंग स्रोत | आपके वर्कलोड के लिए जाँचने योग्य शामिल चीज़ें |
|---|---|
| Bird प्राइसिंग | भेजने का अलाउंस, ओवरेज, डेडिकेटेड इंफ़्रास्ट्रक्चर, रिटेन्ड कंटेंट और सपोर्ट |
| Amazon SES प्राइसिंग | आउटबाउंड और इनबाउंड उपयोग, डेटा चार्ज, डेडिकेटेड IP और वैकल्पिक फ़ीचर |
| SendGrid प्राइसिंग | प्लान वॉल्यूम, ओवरेज, डेडिकेटेड IP पात्रता, एक्टिविटी रिटेंशन और सपोर्ट |
| Mailgun प्राइसिंग | भेजने की मात्रा, लॉग और मैसेज रिटेंशन, डेडिकेटेड IP और सपोर्ट |
| Postmark प्राइसिंग | भेजने का अलाउंस, अतिरिक्त वॉल्यूम, रिटेंशन विकल्प और डेडिकेटेड IP पात्रता |
| Resend प्राइसिंग | भेजने और प्राप्त करने के अलाउंस, ओवरेज, रिटेंशन और डेडिकेटेड IP पात्रता |
जाँचें कि उद्धृत अलाउंस रिक्वेस्ट, मैसेज या प्राप्तकर्ता गिनता है। शामिल न किए गए फ़ीचर प्लान के साथ रिकॉर्ड करें, न कि यह मान लें कि वे शामिल हैं। Bird की प्रोवाइडर तुलनाएँ अलग-अलग प्रोडक्ट तुलनाएँ प्रस्तुत करती हैं।
अक्सर पूछे जाने वाले प्रश्न
ट्रांज़ैक्शनल और मार्केटिंग ईमेल में क्या अंतर है?
ट्रांज़ैक्शनल मेल किसी लेन-देन या अकाउंट गतिविधि की सेवा करता है। मार्केटिंग मेल कुछ प्रमोट करता है या सब्सक्राइब किए गए कंटेंट को डिलीवर करता है। संदेश का उद्देश्य अंतर निर्धारित करता है, तब भी जब दोनों स्वचालित हों।
क्या एक प्रोवाइडर ट्रांज़ैक्शनल और मार्केटिंग दोनों मेल संभाल सकता है?
एक प्रोवाइडर दोनों वर्कफ़्लो की सेवा कर सकता है। कैटेगरी पॉलिसी, प्रमाणित भेजने की पहचान और IP पूल चयन की अलग-अलग जाँच करें। साझा इंफ़्रास्ट्रक्चर अभी भी ऑपरेशनल मेल को मार्केटिंग ट्रैफ़िक की रेप्युटेशन समस्याओं से प्रभावित कर सकता है।
क्या मुझे डेडिकेटेड IP चाहिए?
शुरू में नहीं। कम वॉल्यूम पर शेयर्ड IP पूल ठीक काम करते हैं और आपको IP वार्मअप से बचाते हैं। डेडिकेटेड IP तब सही रहता है जब आपकी मात्रा अपनी रेप्युटेशन बनाए रखने के लिए पर्याप्त अधिक और स्थिर हो। ऐसा प्रोवाइडर चुनें जो आपको शेयर्ड से शुरू करने और संख्याएँ उचित होने पर डेडिकेटेड पर जाने दे।
Bird कहाँ फ़िट होता है
आप SMTP या HTTP API के ज़रिए सबमिट कर सकते हैं। पुन: उपयोग योग्य कंटेंट के लिए टेम्पलेट प्रकाशित करें। प्राप्तकर्ता इवेंट सब्सक्राइब करें। ईमेल लॉग में व्यक्तिगत संदेशों का निरीक्षण करें।
मैसेज कैटेगरी से अलग IP पूल चुनें। भेजने की मात्रा बदलते समय वार्मअप मार्गदर्शन का पालन करें। डुप्लिकेट हैंडलिंग और रिकवरी का परीक्षण करने के लिए ऑपरेशनल चेकलिस्ट का उपयोग करें।
अंतिम चुनाव कैसे करना चाहिए?
- डॉक्यूमेंटेड इंटरफ़ेस और प्राप्तकर्ता नियंत्रणों को अपने एप्लिकेशन से मैच करें।
- पीक ट्रैफ़िक और बैकलॉग रिकवरी दोनों के लिए प्रभावी कोटा की पुष्टि करें।
- सेव किए गए मैसेज और बिज़नेस-इवेंट रिकॉर्ड के विरुद्ध विफलता हैंडलिंग का परीक्षण करें।
- जो प्लान आप खरीदेंगे, उसके लिए प्रकाशित शामिल चीज़ों, रिटेंशन और सपोर्ट की तुलना करें।