الأحداث والطوابير: كيف تبني أتمتة لا تفقد رسالة
لماذا يفشل التنفيذ المباشر داخل الطلب، وكيف تنقل العمل إلى طابور دون أن تفقد الرؤية أو الترتيب.
«عند شراء دورة: سجّل الطلب، وأرسل بريداً، وأضف المتدرّب لقائمة، وأبلغ نظام العميل.» كتابة هذا داخل معالج الطلب مباشرة يعمل تماماً — حتى يتأخّر مزوّد البريد ثوانيَ ويصبح الشراء بطيئاً، أو يفشل النداء الأخير فيُلغى كل شيء رغم نجاح الدفع.
افصل ما يجب أن يحدث الآن
داخل الطلب: ما لا يمكن للمستخدم المتابعة بدونه — تسجيل الشراء ومنح الوصول. خارجه: كل ما يمكن أن يحدث بعد ثانية دون أن يلاحظ أحد — البريد، والمزامنة، والتقارير. القاعدة بسيطة: إن كان فشله لا يجب أن يُفشل العملية، فلا مكان له في الطلب.
الطابور يغيّر ضمانات مختلفة
- التسليم مرة على الأقل هو الافتراض السائد: قد تصل الرسالة مرتين، فيجب أن يكون المعالج آمن التكرار.
- الترتيب ليس مضموناً غالباً؛ إن احتجته، فرضه بمفتاح تقسيم لا بالأمل.
- لكل رسالة عدد محاولات محدود، وما يتجاوزه يذهب إلى طابور الرسائل الميتة لا إلى العدم.
- التأخّر مقياس تشغيلي أساسي: طابور يتراكم أسوأ من طابور يفشل، لأنه يفشل بصمت.
إعادة المحاولة بتراجع أسّي
إعادة المحاولة فوراً تضاعف الحمل على خدمة متعثّرة أصلاً فتُسقطها تماماً. باعد بين المحاولات بشكل متزايد، وأضف تشويشاً عشوائياً حتى لا تعيد كل العمّال المحاولة في اللحظة نفسها. وميّز بين الفشل المؤقّت الذي يستحق إعادة والفشل الدائم الذي لا معنى لإعادته — بريد غير صالح لن يصبح صالحاً بعد خمس محاولات.
طابور الرسائل الميتة ليس اعترافاً بالهزيمة، بل الفرق بين خطأ تراه وخطأ يختفي.
الرؤية أهم من الأناقة
أسوأ ما في العمل غير المتزامن أنه يفشل بعيداً عن عين المستخدم. اجعل لكل مهمة معرّفاً يمكن تتبّعه من الحدث الأصلي، وسجّل عدد المحاولات وسبب آخر فشل، وابنِ شاشة بسيطة تعرض المتراكم والفاشل. بدونها ستكتشف المشكلة من شكوى عميل.
متى لا تحتاج طابوراً
لا تبنِ بنية أحداث كاملة لثلاث مهام خلفية. ابدأ بأبسط شكل يفصل العمل عن الطلب، وانتقل إلى طوابير متعدّدة بأولويات حين يصبح لديك عمل بطيء يزاحم عملاً حسّاساً للوقت — لا قبل ذلك.
أفضل ما كُتب عن التراجع الأسّي والتشويش العشوائي هو مقالة مكتبة بنّائي AWS عن المهل وإعادة المحاولة، بأرقام ورسوم لا بنصائح عامة. وللأنماط نفسها بمفردات مستقرة، Enterprise Integration Patterns ما زال المرجع، وكتاب Google SRE يغطي التعامل مع الحمل الزائد.
ولمن يبني: أكثر ما يُبنى خطأً هنا هو افتراض أن الرسالة تصل مرة واحدة. تحدّث إلينا.
أسئلة شائعة
كيف أجعل المعالج آمن التكرار؟
اجعل لكل حدث معرّفاً فريداً، وسجّل ما عولج، وتحقّق قبل التنفيذ. أو صمّم العملية بحيث يعطي تنفيذها مرتين نفس النتيجة.
كم محاولة قبل الرسالة الميتة؟
خمس محاولات على مدى ساعات تغطي الأعطال المؤقّتة؛ ما يفشل بعدها يحتاج تدخّلاً لا محاولة سادسة.
هل أحتاج نظام رسائل متخصّصاً؟
ليس في البداية. جدول مهام في قاعدتك مع قفل صحيح يكفي حتى حجم معتبر، وأبسط بكثير في التشغيل.