طراحی سامانه پیامکی سازمانی؛ صف ارسال، تحویل و مدیریت خطا

پیامک سازمانی یک سرویس عملیاتی است

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

تفکیک انواع پیام

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

طراحی معماری ارسال

معماری معمول شامل برنامه مبدأ، API داخلی، صف پیام، worker ارسال، درگاه ارائه‌دهنده و سرویس دریافت گزارش است. برنامه مبدأ نباید برای هر پیام منتظر پاسخ نهایی اپراتور بماند. ابتدا درخواست معتبر ثبت و شناسه پیگیری تولید می‌شود؛ سپس worker آن را ارسال می‌کند. این تفکیک باعث می‌شود اختلال موقت ارائه‌دهنده کل برنامه سازمانی را متوقف نکند. وضعیت هر مرحله باید در پایگاه داده پایدار ذخیره شود.

صف پایدار و جلوگیری از گم‌شدن پیام

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

اولویت‌بندی و سهمیه ارسال

پیام‌های ورود و امنیتی باید اولویت بالاتری از کمپین‌های اطلاع‌رسانی داشته باشند. صف می‌تواند بر اساس نوع پیام، مشتری، خط ارسال یا زمان ایجاد تفکیک شود. سهمیه هر tenant مانع مصرف تمام ظرفیت توسط یک مشتری می‌شود. اولویت نباید به معنی حذف کامل عدالت در صف باشد؛ پیام‌های کم‌اولویت نیز باید در محدوده زمانی تعریف‌شده پردازش شوند. ظرفیت هر صف با محدودیت ارائه‌دهنده هماهنگ گردد.

کنترل نرخ و محدودیت ارائه‌دهنده

درگاه پیامک معمولاً محدودیت نرخ، تعداد درخواست هم‌زمان یا سقف اعتبار دارد. ارسال بیش از ظرفیت می‌تواند پاسخ خطا یا مسدودشدن موقت ایجاد کند. worker باید نرخ را کنترل و پاسخ محدودیت را تفسیر کند. retry سریع و بدون فاصله می‌تواند فشار را بیشتر کند. نرخ مجاز باید از مستندات و تجربه واقعی ارائه‌دهنده استخراج شود و برای هر خط یا حساب جداگانه قابل تنظیم باشد.

مدیریت Retry و Backoff

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

شناسه پیام و Idempotency

هر پیام داخلی باید شناسه یکتا داشته باشد و در صورت امکان شناسه متناظر ارائه‌دهنده نیز ذخیره شود. کلید idempotency می‌تواند از tenant، درخواست مبدأ و شناسه رویداد تشکیل شود. اگر همان درخواست دوباره دریافت شد، پاسخ قبلی برگردانده شود و پیام جدیدی ساخته نشود. این کنترل باید در سمت سرور انجام شود؛ تکیه بر رفتار کلاینت کافی نیست. مدت نگهداری کلیدها با احتمال retry و نیاز ممیزی هماهنگ باشد.

وضعیت‌های پیام و مفهوم تحویل

پذیرفته‌شدن درخواست توسط API به معنی تحویل به گوشی نیست. وضعیت‌هایی مانند ثبت‌شده، در صف، ارسال‌شده به اپراتور، تحویل‌شده، ناموفق و نامشخص باید از هم تفکیک شوند. همه ارائه‌دهندگان گزارش تحویل یکسانی ندارند و برخی وضعیت‌ها ممکن است با تأخیر برسند. رابط کاربری باید معنای هر وضعیت را توضیح دهد تا مدیر تصور نکند هر پیام پذیرفته‌شده حتماً به مخاطب رسیده است.

دریافت Delivery Report

گزارش تحویل ممکن است از طریق webhook یا polling دریافت شود. webhook باید امضای معتبر یا روش احراز هویت داشته باشد و در برابر ارسال تکراری مقاوم باشد. شناسه پیام برای تطبیق گزارش با درخواست اولیه ضروری است. اگر callback موقتاً در دسترس نباشد، باید امکان دریافت مجدد یا تطبیق دوره‌ای وجود داشته باشد. وضعیت نهایی تنها پس از بررسی گزارش معتبر به‌روزرسانی شود.

مدیریت شماره و خط ارسال

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

مدیریت OTP و کد یک‌بارمصرف

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

قالب پیام و متغیرها

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

هزینه و شمارش قطعه پیام

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

چندمشتری و تفکیک اعتبار

در سامانه چندمشتری، هر کسب‌وکار باید تنظیمات، اعتبار، خط و گزارش خود را داشته باشد. credential یک مشتری نباید در درخواست یا log مشتری دیگر ظاهر شود. سهمیه و هزینه بر اساس tenant محاسبه گردد. مدیر مرکزی می‌تواند وضعیت کلی را ببیند، اما دسترسی به متن پیام و اطلاعات مخاطب باید بر اساس نقش و ضرورت محدود شود. شناسه tenant از نشست معتبر استخراج شود، نه از ورودی قابل جعل کلاینت.

اتصال به CRM و ERP

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

امنیت API و کلیدها

کلید API باید محرمانه، قابل ابطال و محدود به عملیات لازم باشد. کلیدها در کد منبع، مرورگر یا log قرار نگیرند. ارتباط TLS، محدودیت نرخ، کنترل IP در صورت امکان و ثبت رخدادهای احراز هویت لازم‌اند. دسترسی ارسال و مشاهده گزارش می‌تواند جدا شود. در صورت افشای کلید، فرایند تعویض و بررسی پیام‌های غیرمجاز باید وجود داشته باشد.

حریم خصوصی و محتوای پیام

شماره تلفن و متن پیام ممکن است اطلاعات شخصی یا مالی داشته باشند. داده‌ای بیش از نیاز در سامانه ذخیره نکنید و دوره نگهداری را مشخص سازید. در گزارش عمومی می‌توان شماره را ماسک کرد. دسترسی به متن کامل پیام باید محدود و قابل ممیزی باشد. پیام تبلیغاتی باید بر اساس رضایت و مقررات مربوط ارسال شود و درخواست لغو دریافت در فهرست منع ارسال اعمال گردد.

پایش و هشدار عملیاتی

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

تداوم خدمت و ارائه‌دهنده جایگزین

وابستگی به یک ارائه‌دهنده می‌تواند در زمان اختلال کل اطلاع‌رسانی را متوقف کند. مسیر جایگزین باید از قبل آماده و آزمایش شده باشد. انتقال خودکار همه پیام‌ها به ارائه‌دهنده دوم ممکن است هزینه و ریسک تکرار ایجاد کند؛ ابتدا وضعیت ارسال قبلی بررسی شود. سیاست failover باید نوع پیام، وضعیت قطعی و محدودیت‌های خطوط را در نظر بگیرد.

آزمون قبل از بهره‌برداری

آزمون باید ارسال موفق، شماره نامعتبر، اعتبار ناکافی، timeout، callback تکراری، قطعی شبکه، پرشدن صف و restart worker را پوشش دهد. همچنین باید بررسی شود که پیام حساس در log ذخیره نمی‌شود و retry باعث ارسال تکراری نیست. محیط آزمایشی و شماره‌های تست از مخاطبان واقعی جدا باشند. نتیجه آزمون و محدودیت‌های شناخته‌شده ثبت شوند.

جمع‌بندی

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