المهام الخلفية والطوابير لبناء أنظمة Backend موثوقة

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

هذه هي المشكلة التي تحلها الـ background jobs والـ queues. فهي تتيح لتطبيقك أن يقول "تم الاستلام" فورًا، ثم يؤدي العمل الثقيل بعد ذلك بطريقة موثوقة، حتى عندما تتعثر بعض الخدمات. وبالنسبة لأي منتج يتعامل مع أموال حقيقية أو مستخدمين حقيقيين، فهذا ليس رفاهية، بل هو الفارق بين backend يبدو سريعًا وآخر ينهار تحت الضغط.

ما هي الـ background jobs فعليًا

الـ background job هو وحدة عمل يؤجلها تطبيقك بدلًا من تنفيذها فورًا. فبدلًا من إتمام المهمة داخل طلب المستخدم، تدفع رسالة صغيرة تصف المهمة إلى queue، ثم تُرجع ردًا، وتترك عملية منفصلة، تُسمى worker، تلتقطها وتنفذها.

الـ queue هو الحاجز الوسيط الذي يحفظ المهام بالترتيب حتى يتفرغ أحد الـ workers. أما الـ workers فهي عمليات (غالبًا عدة عمليات تعمل بالتوازي) تسحب المهام من الـ queue وتنفذها. هذا الفصل يمنحك ثلاثة مكاسب في آن واحد:

• سرعة للمستخدم. يُرجع الطلب رده فور إضافة المهمة إلى الـ queue، غالبًا خلال أجزاء من الثانية.
• مرونة وصمود. إذا تعطل أحد الـ workers في منتصف المهمة، تبقى المهمة في الـ queue وتُعاد محاولتها.
• تحكم في الحِمل. يمكنك تشغيل عدد أكبر من الـ workers في ساعات الذروة وأقل ليلًا، فتُمتص الموجات المفاجئة بدلًا من إغراق خوادمك.

أمثلة شائعة ننفذها للعملاء: إرسال رسائل البريد الإلكتروني والـ SMS التشغيلية، وإنشاء فواتير PDF، ومعالجة الصور والفيديو المرفوعة، ومزامنة البيانات مع أنظمة المحاسبة أو الـ POS، وتشغيل التقارير المجدولة، واستدعاء واجهات API بطيئة لطرف ثالث.

لماذا تجعل الـ queues الـ backend موثوقًا

الوعد الجوهري لأي queue جيد هو أن المهمة إما أنها أُنجزت، أو أنها ما تزال تنتظر الإنجاز، فهي لا تختفي بصمت. هذا الضمان هو ما يحوّل سلسلة هشة من استدعاءات الـ API إلى نظام يُعتمد عليه.

إعادة المحاولة والـ backoff

تفشل الخدمات الخارجية باستمرار: تنتهي مهلة معالج الدفع، أو يفرض مزود البريد حدًا على معدل الطلبات، أو يُرجع مزود الشحن خطأ 500. مع الـ background jobs، تُعاد محاولة المهمة الفاشلة تلقائيًا، عادة مع exponential backoff، أي أن الفجوات بين المحاولات تتسع (10 ثوانٍ، ثم 30، ثم دقيقتان). وهكذا تُحل الأعطال المؤقتة من تلقاء نفسها دون أن يستيقظ أحد في الثالثة فجرًا.

الـ dead-letter queues

بعض المهام تفشل فشلًا حقيقيًا: سجل تالف، أو مورد محذوف نهائيًا. بعد عدد محدد من المحاولات، تُنقل هذه المهام إلى dead-letter queue، وهو منطقة احتجاز للمهام التي تحتاج إلى مراجعة بشرية. لا يضيع شيء، ويبقى الـ queue الرئيسي نظيفًا ومنسابًا.

الـ Idempotency

لأن المهام قابلة لإعادة المحاولة، يجب أن يكون تشغيلها أكثر من مرة آمنًا. فخصم قيمة من العميل مرتين بسبب إعادة محاولة مهمة خطر حقيقي. والحل هو الـ idempotency، أي تصميم كل مهمة بحيث ينتج عن تشغيلها مجددًا النتيجة نفسها. النمط المعتاد هو تسجيل مفتاح فريد لكل عملية والتحقق منه قبل التنفيذ، بحيث تصبح المحاولة الثانية بلا أثر.

اختيار الأدوات المناسبة

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

مدمجة داخل إطار العمل

إذا كنت تعمل على Laravel، فنظام الـ queue موجود بالفعل. المهام، وإعادة المحاولة، والتأخير، وجدول failed_jobs كلها جاهزة، مع Redis أو قاعدة بيانات كطبقة خلفية. ولمعظم المنتجات الصغيرة والمتوسطة، هذا أكثر من كافٍ ويتجنب أجزاء متحركة إضافية.

أما في Node.js، فإن BullMQ فوق Redis خيار قوي ومدعوم جيدًا، يوفر مهامًا مؤجلة، وجداول متكررة، ولوحة تحكم نظيفة.

وسطاء الرسائل المتخصصون

عندما يرتفع معدل الإنتاجية أو تحتاج إلى أن تتفاعل عدة خدمات مع الحدث نفسه، يثبت الوسيط المتخصص جدارته:

• Redis — بسيط وسريع، مثالي لمعظم الـ job queues.
• RabbitMQ — توجيه غني، مناسب عندما يحتاج عدة مستهلكين إلى شرائح مختلفة من المسار نفسه.
• Kafka — مصمم لتدفقات الأحداث عالية الحجم ومسارات التحليلات.
• الـ queues السحابية المُدارة (AWS SQS، Google Cloud Tasks) — لا خوادم تصونها، وتدفع حسب الاستخدام، وهي منطقية للفرق الموجودة أصلًا على تلك المنصات.

قاعدة عملية: ابدأ بما يوفره إطار عملك، ولا تنتقل إلى وسيط متخصص إلا عندما يدفعك إليه حِمل مُقاس أو حاجة معمارية واضحة. فالتعقيد المبكر يكلف أكثر مما يوفر.

أخطاء شائعة يجب تجنبها

على مدى السنوات، رأينا الأخطاء نفسها القابلة للتجنب تتكرر مرارًا.

• حشو الـ queue بحمولات ضخمة. ضع معرّفًا (ID) في الرسالة، لا الملف بحجم 5 ميجابايت كاملًا. الـ worker يجلب ما يحتاجه.
• غياب المراقبة. تراكم الـ queue بصمت هو انقطاع خدمة بطيء الحركة. تحتاج إلى رؤية واضحة لعمق الـ queue، وزمن المعالجة، ومعدلات الفشل.
• معاملة كل مهمة كأنها عاجلة. افصل الـ queues حسب الأولوية. رسالة إعادة تعيين كلمة المرور يجب ألا تنتظر خلف 10 آلاف رسالة تسويقية.
• تجاهل الـ idempotency حتى يُخصم من العميل مرتين. صمّم لإعادة المحاولة من اليوم الأول.
• عدم وجود تنبيهات على الـ dead-letter queue. إذا وصلت المهام إلى هناك دون أن يُخطر أحد، فأنت قد بنيت مكانًا تختبئ فيه المشكلات.

أهم النقاط

• تنقل الـ background jobs العمل البطيء أو غير الموثوق خارج طلب المستخدم، فيبدو الـ backend سريعًا ويبقى متجاوبًا تحت الضغط.
• تضيف الـ queues موثوقية عبر إعادة المحاولة مع الـ backoff، والـ dead-letter queues للأعطال الدائمة، وضمان ألا تختفي أي مهمة بصمت.
• صمّم كل مهمة لتكون idempotent حتى لا تتسبب إعادة المحاولة في خصم مزدوج أو إجراء مكرر.
• ابدأ بأدوات الـ queue المدمجة في إطار عملك، ولا تنتقل إلى وسيط متخصص مثل Redis أو RabbitMQ أو Kafka إلا حين يفرض الحِمل الحقيقي ذلك.
• المراقبة والتنبيهات ليست اختيارية، فالـ queue غير المراقَب هو انقطاع خدمة ينتظر الحدوث.

إتقان الـ background jobs والـ queues من أعلى الاستثمارات عائدًا في بناء backend ينمو دون أن ينكسر. وإذا كنت تبني منتجًا تهم فيه الموثوقية، كالمدفوعات أو التوصيل أو الـ POS أو أي شيء يتعامل مع العملاء مباشرة، فإن فريق SummationWorks يصمم ويبني هذه الأنظمة لعملاء في دول الخليج ومصر وخارجها. تعرّف على خدماتنا، واطّلع على أعمالنا، أو تواصل معنا لنناقش ما يحتاجه الـ backend الخاص بك.