كيف طوّرنا - بفضل الله - منظومة إرسال الإيميلات في مرتكز

الحمد لله الذي علَّم بالقلم، علَّم الإنسان ما لم يعلم، والصلاة والسلام على خير معلِّم الناس الخير سيدنا محمد - صلَّى الله عليه وسلم … أما بعد ،،

مع نمو منصة مرتكز وازدياد التفاعل عليها، بدأ نظام إرسال الإيميلات يلعب دوراً أكبر من مجرد وظيفة مساندة.

ظهرت مشكلات لم تعد الحلول البدائية قادرة على تحملها، وكان لابد من خطوة أعمق تعيد بناء المنظومة بالكامل.

في هذا المقال نشارك معكم كيف طورنا - بفضل الله - منظومة إرسال الإيميلات في مرتكز، وما الذي تغيّر خلف الستار، ولماذا أحدث ذلك فرقاً حقيقياً في أداء المنصة واستقرارها.

قبل متابعة المقال، أنصح بالاطلاع على مقالي السابق "تجربتي حول إرسال الإيميلات لمستخدمي تطبيقاتي"، حيث شاركت فيه خلاصة تجربتي مع SendGrid وأبسط النصائح لضمان وصول الإيميلات بموثوقية وأمان.
سيكون ذلك تمهيداً جيداً لفهم الخلفية التي انطلقنا منها قبل بناء المنظومة الجديدة في مرتكز.

كيف كان يعمل النظام القديم ؟ ولماذا لم يعد كافياً ؟

في النسخة الأولى من مرتكز كان إرسال الإيميل يتم مباشرة من داخل الخادم؛ فبمجرد أن يضغط المستخدم زراً ما أو ينشر مشروعاً جديداً، يستدعي النظام واجهة SendGrid على الفور وينتظر الرد قبل إتمام العملية.

هذا الأسلوب كان بسيطاً ومباشراً، ويؤدي الغرض في المراحل الأولى حين كان حجم الاستخدام محدوداً.

لكن مع ازدياد التفاعل، بدأت تظهر قيود واضحة لهذا النموذج؛ فإذا تأخرت خدمة الإرسال لثوانٍ معدودة، اضطر المستخدم للانتظار بلا داعٍ، وأي خطأ مؤقت كان يكفي لإفشال العملية بالكامل.

إضافة إلى ذلك، لم تكن هناك آلية لإعادة المحاولة تلقائياً أو متابعة حالة الرسائل بعد الإرسال.

ومع مرور الوقت أصبح هذا النظام عبئاً على التجربة، وكشف الحاجة الملحّة إلى منظومة أكثر مرونة وموثوقية يمكن الاعتماد عليها مع توسّع المنصة.

كيف أصبح النظام بعد التطوير ؟

في المنظومة الجديدة لم يعد إرسال الإيميل يتم مباشرة أثناء تفاعل المستخدم، بل أصبح يمر عبر سلسلة أكثر ذكاءً وتنظيماً.

تُسجّل الرسالة أولاً في قاعدة البيانات داخل Outbox، ثم تُدفع فوراً إلى طابور BullMQ، ليتولى عامل مستقل (Worker) إرسالها في الخلفية وتحديث حالتها بعد نجاحها أو عند الحاجة لإعادة المحاولة.

هذا الفصل بين واجهة المستخدم وعمليات الإرسال، بالاعتماد على Valkey كخادم سريع للطوابير (Queues)، جعل المنظومة أكثر مرونة وثباتاً وقدرة على التعامل مع ضغط أعلى دون التأثير على تجربة المستخدم.

أما على مستوى النتائج، فقد حقق هذا التطوير نقلة واضحة في الأداء؛ إذ لم يعد المستخدم ينتظر ردّ SendGrid، وأصبح الإرسال أكثر استقراراً حتى في حال حدوث أخطاء مؤقتة.

لم تعد هناك رسائل مفقودة أو مكررة، وأصبح من السهل متابعة حالة كل رسالة بدقة من بدايتها إلى نهايتها.

كذلك بات النظام قادراً على التوسع بسهولة ومعالجة عدد كبير من الإيميلات دون تحميل الخادم عبئاً إضافياً، مما انعكس مباشرة على سرعة المنصة وجودة وموثوقية ارسال الإيميلات.

أفضل الممارسات التي اعتمدناها أثناء التطوير

أثناء إعادة بناء منظومة الإيميل، حرصنا على تبنّي ممارسات راسخة تمنح النظام موثوقية أعلى وقدرة كبيرة على التوسع دون التأثير على تجربة المستخدم .. وفيما يلي أبرز هذه الممارسات:

تطبيق Outbox Pattern كعمود فقري للمنظومة
اعتمدنا على نموذج الـOutbox لفصل خطوة إنشاء الرسالة عن خطوة إرسالها، إذ تُسجَّل الرسالة أولاً في قاعدة البيانات، ثم تُرسل للعامل المتخصص ليعالجها في الخلفية ويحدّث حالتها بعد النجاح، هذا الأسلوب يجعل الإرسال أكثر اتساقاً ويمنع أي تكرار غير مقصود.

استخدام Idempotency كضمان عدم تكرار الرسائل
من خلال تطبيق هذا المفهوم حتى لو حاول النظام إرسال نفس الرسالة أكثر من مرة بسبب خطأ أو إعادة تشغيل، بهذه الطريقة يظل الإيميل يرسل مرة واحدة فقط، مما يحل واحدة من أكثر المشكلات شيوعاً في أنظمة الطوابير.

مهمة تعافي (Recovery) ذكية عند الإقلاع
بدلا من إضافة مهمة تحقق دورية كل بضع ثواني بشكل متكرر، أضفنا مهمة صغيرة تعمل مرة واحدة فقط في كل مرة يتم فيها تشغيل العامل (Worker)؛ تبحث عن الرسائل التي لم تُرسل سابقاً وتعيد دفعها للطابور، ثم تتوقف نهائياً، مما يضمن عدم فقدان أي رسالة، دون الحاجة إلى فحص مستمر يرهق الخادم.

خاتمة

هذا التطوير لم يكن مجرد تحسين مخفي خلف الكواليس، بل كان خطوة جوهرية ارتقت ببنية مرتكز إلى مستوى أعلى من السرعة والموثوقية والقدرة على التوسع.

نؤمن أن بناء منصة عربية تستحق المنافسة عالمياً يبدأ من هذه التفاصيل الدقيقة، التي تُنجز بصبر ودقة وشغف، لتضع أساس متين لمستقبل نطمح فيه أن يقدم مرتكز أفضل ما يمكن لمجتمع المبدعين العرب - بفضل الله أولاً وأخيراً.

زائر مدونتي الكريم، وفقني الله وإياك إلى ما يحبه ويرضاه ،،