Routing پیامک چیست؟ راهنمای مسیریابی هوشمند و انتخاب مسیر ارسال

اگر سازمان شما هم‌زمان OTP، اعلان تراکنش و پیام انبوه می‌فرستد، یک قاعدهٔ ثابت برای همهٔ پیام‌ها کافی نیست. این راهنما برای مدیر فنی، تیم عملیات و ارائه‌دهندهٔ خدمات پیامکی توضیح می‌دهد موتور Routing کجا قرار می‌گیرد، چه اطلاعاتی لازم دارد، چه زمانی Failover منطقی است و کیفیت تصمیم آن چگونه سنجیده می‌شود.

Routing پیامک دقیقاً چه کاری انجام می‌دهد؟

سامانهٔ مبدأ، پیام را به SMS Gateway می‌سپارد. پس از اعتبارسنجی و قرار گرفتن در جریان پردازش، موتور Routing باید از میان مسیرهای قابل استفاده تصمیم بگیرد. «مسیر» ممکن است یک اتصال SMPP یا HTTP به اپراتور، تجمیع‌کننده یا ارائه‌دهندهٔ دیگر باشد. پس از انتخاب، Adapter مربوط پیام را به قالب آن اتصال تبدیل می‌کند. پاسخ اولیه و سپس گزارش تحویل به شناسهٔ پیام برمی‌گردند.

این موضوع با انتخاب متن پیام یا فهرست مخاطبان فرق دارد. Routing در لایهٔ زیرساخت انجام می‌شود و می‌تواند برای هر دسته از پیام‌ها، مقصدها یا مشتریان سیاست جدا داشته باشد. در مقالهٔ معماری SMS Gateway سازمانی جای این موتور در کل زیرساخت توضیح داده شده است؛ اینجا بر منطق تصمیم و ارزیابی خروجی آن تمرکز می‌کنیم.

مسیر یک پیام چگونه انتخاب می‌شود؟

یک موتور مسیریابی قابل اتکا ابتدا دادهٔ پیام را دریافت می‌کند، مسیرهای مجاز را فیلتر می‌کند، مسیرهای باقی‌مانده را می‌سنجد و نتیجه را ثبت می‌کند. نمودار زیر این چرخه را نشان می‌دهد؛ اطلاعات آن در ادامهٔ متن نیز آمده است.

1. شناخت پیام: نوع جریان، مقصد، فرستندهٔ مجاز، مهلت اعتبار و شناسهٔ درخواست مشخص می‌شود.
2. فیلتر صلاحیت: مسیرهایی که برای مقصد، نوع پیام، فرستنده یا قرارداد مربوط مجاز نیستند کنار می‌روند.
3. ارزیابی عملیاتی: سلامت اتصال، ظرفیت باقی‌مانده، تأخیر، نرخ خطا و هزینهٔ مسیرهای مجاز بررسی می‌شود.
4. انتخاب و ارسال: سیاست سازمان مسیر نهایی را تعیین می‌کند؛ انتخاب، زمان و شناسه‌های داخلی و بیرونی ثبت می‌شوند.
5. بازخورد: پاسخ اتصال و گزارش تحویل دریافت می‌شود تا خطا تشخیص داده شود و انتخاب پیام‌های بعدی اصلاح شود.

یک نکتهٔ مهم: موفق بودن پاسخ API یا پذیرش پیام توسط مسیر بیرونی، مساوی تحویل به گوشی نیست. در مستندات وضعیت پیام Twilio نیز حالت‌های accepted، queued، sent و delivered جدا هستند. معنی دقیق هر وضعیت را باید در قرارداد مسیر خود ثبت کنید.

موتور مسیریابی بر چه اساسی تصمیم می‌گیرد؟

مجاز بودن مسیر و فرستنده

نخستین شرط، امکان استفادهٔ واقعی از مسیر است. شماره یا شناسهٔ فرستنده باید برای مقصد و نوع پیام قابل استفاده باشد؛ محدودیت قراردادی، سیاست مشتری و الزامات محلی نیز باید رعایت شوند. این بخش مقدم بر امتیازدهی است: مسیری که سریع یا ارزان باشد اما برای پیام مجاز نباشد، نامزد انتخاب نیست. رفتار انتخاب فرستنده در سرویس‌های پیام‌رسان هم می‌تواند به کشور مقصد و نوع فرستنده وابسته باشد؛ مستندات Twilio نمونه‌ای از این منطق را نشان می‌دهد، نه قاعده‌ای یکسان برای همهٔ بازارها.

سلامت و ظرفیت لحظه‌ای

باز بودن اتصال به‌تنهایی نشانهٔ آمادگی نیست. نرخ پاسخ خطا، زمان پاسخ، محدودیت نرخ ارسال، عمق صف و ظرفیت آزادِ همان مسیر باید دیده شوند. اگر یک مسیر در دقیقهٔ اخیر کند شده یا سقف قراردادش پر است، فرستادن ترافیک بیشتر به آن می‌تواند تأخیر را تشدید کند. در راهنمای گلوگاه‌های Peak Traffic توضیح داده‌ایم چگونه تأخیر را میان API، صف، موتور مسیر و اتصال خروجی تفکیک کنید.

اولویت جریان و مهلت پیام

برای OTP که اعتبار کوتاهی دارد، تأخیر و احتمال ارسال به‌موقع معمولاً وزن بیشتری از هزینه دارند. اعلان تراکنشی نیز به وضعیت قابل رهگیری نیاز دارد. در ارسال انبوه، ظرفیت و هزینه ممکن است وزن بالاتری بگیرند، البته فقط میان مسیرهای مجاز و با کیفیت پذیرفتنی. پیام منقضی‌شده نباید صرفاً به دلیل باز شدن یک مسیر دوباره فرستاده شود؛ مهلت اعتبار باید بخشی از سیاست صف و Routing باشد.

کیفیت، هزینه و تجربهٔ گیرنده

«کیفیت» را با یک درصد کلی نسنجید. نرخ تحویل، تأخیر تا تحویل و خطاها را به تفکیک مقصد، نوع پیام، ساعت و مسیر مقایسه کنید. هزینه نیز باید با کیفیت و قواعد قانونی سنجیده شود؛ ارزان‌ترین مسیر اگر پیام‌های حساس را دیر یا بی‌وضعیت تحویل دهد، انتخاب اقتصادی خوبی نیست. یک قاعدهٔ سادهٔ قابل توضیح معمولاً از امتیازی که دادهٔ معتبر ندارد مفیدتر است.

انواع روش‌های Routing پیامک

این روش‌ها رقیب مطلق هم نیستند. در عمل، ابتدا قواعد صلاحیت اعمال می‌شود، سپس میان مسیرهای مجاز اولویت یا وزن تعیین می‌شود و برای رخدادهای تعریف‌شده مسیر جایگزین در نظر گرفته می‌شود. صفحهٔ رسمی تلیرکو از Smart Routing Engine، انتخاب بر اساس کیفیت و هزینه و اتصال‌های متعدد همراه با Failover نام می‌برد. جزئیات قواعد، شاخص‌ها و نحوهٔ استقرار باید برای پروژهٔ شما مشخص شود.

Failover چه زمانی کمک می‌کند و چه زمانی خطرناک است؟

اگر اتصال اصلی پیش از پذیرش پیام به‌روشنی خطا بدهد، تلاش روی یک مسیر مجاز دیگر می‌تواند منطقی باشد. اما اگر اتصال پاسخ نداده و وضعیت پذیرش نامعلوم است، ارسال دوباره ممکن است دو پیام به گیرنده برساند. بنابراین خطاها را دست‌کم به سه گروه تقسیم کنید: رد قطعی پیش از پذیرش، شکست قطعی پس از پذیرش و وضعیت نامعلوم. سیاست retry و Failover برای هر گروه باید متفاوت باشد.

برای کنترل تکرار، شناسهٔ داخلی درخواست، شناسهٔ ارسال در مسیر بیرونی، زمان هر تلاش و آخرین وضعیت را نگه دارید. کلید idempotency در ورودی، ثبت تلاش‌ها و بررسی وضعیت نامعلوم پیش از ارسال مجدد کمک می‌کنند؛ البته تضمین نهایی به قابلیت مسیر و قرارداد آن بستگی دارد. منطق صف نیز مهم است: مستندات Amazon SQS نشان می‌دهد در پردازش ناهمگام، تحویل دوبارهٔ یک کار ممکن است رخ دهد. این اصل عمومی را باید در طراحی کارگرهای ارسال نیز در نظر گرفت.

کیفیت Routing را با چه شاخص‌هایی بسنجیم؟

• زمان تصمیم: فاصلهٔ آماده شدن پیام در موتور تا انتخاب مسیر.
• زمان صف و ارسال: فاصلهٔ پذیرش درخواست تا تحویل به اتصال بیرونی؛ برای تشخیص گلوگاه، این دو را جدا ثبت کنید.
• نرخ رد و خطای مسیر: به تفکیک دلیل، مشتری، جریان و اتصال.
• نرخ و زمان تحویل: فقط برای پیام‌هایی که وضعیت نهایی قابل اتکا دارند و با تفکیک مقصد و ساعت.
• سهم ترافیک هر مسیر: مقایسه با وزن و ظرفیت تعریف‌شده، برای کشف انحراف.
• تعداد تلاش‌های مجدد و موارد تکراری: برای سنجش اثر Failover بر تجربهٔ گیرنده.
• پیام‌های بی‌وضعیت: مواردی که پاسخ اولیه دارند اما گزارش نهایی قابل نگاشت ندارند.

گزارش تحویل یا DLR برای این تحلیل مهم است. در SMPP، درخواست گزارش تحویل با فیلد registered_delivery ثبت می‌شود و رسید می‌تواند در deliver_sm یا data_sm بازگردد. پشتیبانی و قالب دقیق گزارش به اتصال بیرونی وابسته است. تصمیم عملیاتی را بر داده‌ای بسازید که واقعاً دریافت و به پیام درست نگاشت شده است.

یک مثال: مسیر OTP و پیام انبوه یکسان نیست

فرض کنید دو اتصال مجاز دارید. مسیر «الف» سریع‌تر است ولی ظرفیت محدودتری دارد؛ مسیر «ب» ظرفیت بیشتری دارد و معمولاً ارزان‌تر است. در ساعت اوج، برای OTP معتبر و حساس به زمان، موتور می‌تواند پس از کنترل سلامت و ظرفیت، مسیر «الف» را در اولویت بگذارد. برای اعلان انبوه، بخشی از ترافیک را طبق سهم تعریف‌شده به «ب» بفرستد. اگر «الف» رد قطعی یا اختلال قابل تشخیص داشته باشد، موتور مسیر جایگزین را بررسی کند؛ اگر وضعیت پذیرش نامعلوم باشد، پیش از تلاش دوم وضعیت را تعیین یا مورد را برای رسیدگی جدا کند.

این صرفاً مثال طراحی است و به معنای رفتار قطعی یک محصول یا کیفیت یک اپراتور مشخص نیست. نتیجهٔ مناسب را باید با ترافیک، قرارداد و شاخص‌های واقعی خودتان آزمون کنید.

چک‌لیست کوتاه طراحی مسیریابی پیامک

1. برای هر جریان پیام، مقصدها، فرستنده‌های مجاز و مهلت اعتبار را بنویسید.
2. قواعد حذف مسیر نامجاز را از قواعد امتیازدهی جدا کنید.
3. ظرفیت، محدودیت نرخ و شاخص سلامت را برای هر اتصال مستقل اندازه بگیرید.
4. معنای پاسخ اولیه، رد قطعی، وضعیت نامعلوم و DLR را در قرارداد تعریف کنید.
5. برای retry و Failover سقف تلاش، بازهٔ زمانی و کنترل تکرار بگذارید.
6. با آزمون بار و قطع اتصال، عملکرد مسیر اصلی و جایگزین را بسنجید.
7. قواعد را نسخه‌بندی کنید تا بتوانید علت انتخاب هر پیام را بعداً توضیح دهید.

پرسش‌های رایج دربارهٔ Routing پیامک

Routing پیامک با SMS Gateway چه تفاوتی دارد؟

Gateway لایهٔ کلی پذیرش، صف، اتصال، پایش و گزارش وضعیت است. Routing یکی از اجزای آن است که مسیر خروجی هر پیام را بر اساس قواعد و داده‌های عملیاتی انتخاب می‌کند.

آیا بهترین مسیر همیشه ارزان‌ترین مسیر است؟

خیر. مسیر باید نخست مجاز و در دسترس باشد؛ سپس کیفیت، ظرفیت، تأخیر، هزینه و مهلت پیام در کنار هم سنجیده شوند. وزن هر معیار به نوع پیام و هدف سازمان بستگی دارد.

آیا Failover تحویل پیامک را تضمین می‌کند؟

خیر. Failover امکان بررسی مسیر جایگزین را فراهم می‌کند. تحویل نهایی به وضعیت گیرنده، شبکه، قواعد ارسال و گزارش مسیر بیرونی نیز وابسته است.

مسیریابی هوشمند بدون DLR هم ممکن است؟

قواعد ثابت و شاخص‌های اتصال بدون DLR هم قابل اجرا هستند، اما سنجش کیفیت تحویل ناقص می‌شود. باید معلوم باشد کدام تصمیم بر پاسخ اولیه و کدام بر وضعیت نهایی متکی است.

منابع فنی: صفحهٔ رسمی SMS Gateway تلیرکو؛ Twilio، انتخاب فرستنده در Messaging Services؛ Twilio، چرخهٔ وضعیت پیام؛ SMPP، گزارش تحویل؛ AWS، پردازش دوباره در صف. نمونه‌های دیگر ارائه‌دهندگان برای توضیح اصول فنی‌اند و به معنای یکسان بودن پیاده‌سازی آن‌ها با تلیرکو نیستند.