حل التعامل مع الأحداث الكتيرة في الباك اند بسهولة

ازاي تهندل Events كتير في نفس اللحظة كمبرمج Backend؟
في البوست ده يا صديقي هنتكلم عن مشكلة بتحصل في أي سيستم كبير…
وهي:
إزاي تهندل Events كتيرة بتحصل في نفس الوقت من غير ما السيستم يولّع؟

الموضوع مهم جدًا لأي حد شغال Backend سواء في ERP، CRM، E-commerce، أو حتى Microservices… لأن طريقة التعامل مع الـ events ممكن تكون الفرق بين سيستم ثابت… وسيستم بيقع من نظرة .

فشمر كمك، حضّر قهوتك ، وتعالى نفكر سوا خطوة بخطوة.

---

المشكلة بتبدأ منين؟ ​

تخيّل معايا إن عندك نظام ERP وحد بيطلّع فاتورة مبيعات.
من برّه ده شكلها عملية بسيطة… لكن تحت السطح؟
هي غابة Events شغالة ورا بعض!

خليني أقولك إيه اللي بيحصل فعلًا:
هل المنتج موجود في المخزن؟
لازم نتأكد من الكمية قبل ما نسمح بالبيع.
هل عليه ضريبة ولا معفى؟
إدارة الضرائب لازم تاخد حقها .
تقرير حركة المخزون
لازم نسجل خروج المنتج من المخزن.
حساب أرباح الفاتورة
تحسب سعر التكلفة + هامش الربح + إجمالي أرباح اليوم.
إرسال Notification للسيستم كله
عشان الموظفين يعرفوا إن في منتج خرج.
التأكد من رصيد العميل
رصيده يسمح؟ ولا لازم يدفع؟ ولا الفاتورة كلها آجلة؟
تقرير الإقرار الضريبي
لو الفاتورة Taxable لازم تدخل في التقارير الشهرية.
تقرير حركة المنتج نفسه
تاريخ كامل للمنتج داخل وخارج المخزن.

ولو قعدنا نكمل… مش هنخلص!
لأن كل عملية من دول تعتبر Event… والـ Events دي لازم تشتغل في نفس اللحظة.

---

المشكلة الأكبر: الحفاظ على الكود Clean ​

أهم سؤال بقى:
إزاي تنفّذ كل الـ events دي من غير ما الكود يتحول لسباجيتي؟

ولو حد طلب تعديل؟
ولو العميل حب يزود feature؟
ولو ظهرت مشكلة في Conditional بسيط؟

اللي مش منظم الكود عمره ما هيعرف يصلّح…
وهيقعد كل يوم يقول:
"مين اللي كتب الكود ده؟"
ويطلع هو اللي كتبه أصلاً .

---

Microservices؟ سيبك منها شوية ​

قبل ما تقوللي "طب نعملها Microservices؟"
استهدى بالله يا صديقي

الموضوع اللي هقولهولك هنا لو فهمته كويس…
تقدر تبني Microservices بنص مجهود.
خلينا الأول نحل المشكلة داخل سيستم Monolith.

---

الحل الذهبي: الـ Observer Pattern ​

لو في Design Pattern لازم تعرفه كويس… فده Observer Pattern.

فكرته ببساطة:​

• عندك Class رئيسي
• ومجموعة “مشتركين” بتتبلغ لما Event يحصل
• أول ما الـ Event يشتغل → كل المشتركين يشتغلوا لوحدهم

وده بالظبط اللي محتاجه الـ ERP و أي سيستم كبير:
Event يحصل → باقي العمليات تتنفّذ تلقائيًا.

مثال لطيف يخليه يدخل دماغك:​

تخيّل إن عندنا مطعم
ودخل عميل جديد.

إيه اللي بيحصل؟
• الكاشير يبدأ يسجّل الطلب
• الشيف يجهّز الأكل
• اللي بيجهز السفرة يجهز الطاولة
• موظف الطلبيات يجهز الفاتورة

محدش بيقول للتاني “اشتغل”…
هو Event واحد (دخول العميل)
وكل دور بيشتغل اوتوماتيك.

وده هو جوهر الـ Observer

---

الـ Observer موجود حوالينا في كل مكان ​

أغلب اللغات والأنظمة مبنية بداخليًا على فكرة الـ Observer:

• في JavaScript عندك:
  addEventListener() ← ده Observer جاهز.
• في Laravel عندك Events & Listeners.
• في Node.js عندك EventEmitter.
• في React عندك State subscriptions.
• في Kafka / RabbitMQ نفس الفكرة بس على مستوى أعلى.

---

مثال عملي في Node.js باستخدام EventEmitter ‍​

لو إنت Backend Node.js - الموضوع أسهل بكتير مما تتخيل.

أولاً: نستورد EventEmitter​

const EventEmitter = require('events');
const myEmitter = new EventEmitter();

نضيف الـ Listeners (المشتركين)​

myEmitter.on('invoiceCreated', () => {
  console.log("✔ التحقق من وجود المنتج في المخزن");
});

myEmitter.on('invoiceCreated', () => {
  console.log("✔ حساب الضريبة");
});

myEmitter.on('invoiceCreated', () => {
  console.log("✔ تحديث حركة المخزون");
});

myEmitter.on('invoiceCreated', () => {
  console.log("✔ إرسال Notification للموظفين");
});

نشغّل الـ Event الرئيسي​

myEmitter.emit('invoiceCreated');

النتيجة:​

✔ التحقق من وجود المنتج في المخزن
✔ حساب الضريبة
✔ تحديث حركة المخزون
✔ إرسال Notification للموظفين

شايف؟
Event واحد → تشغيل أحداث كتير…
ومن غير ما تضرب المشروع كله .

---

ليه الـ Observer بيحل المشكلة؟ ​

لأنك ببساطة:

بتفصل المسؤوليات (SRP).​

كل Listener مسؤول عن مهمة واحدة بس.

تقدر تزود Events جديدة من غير ما تبوظ القديم.​

يعني لو بكرة العميل قال:
“عايز أضيف Report جديد”…
تعمل Listener جديد وتضيفه للـ Event وخلاص ✓
ولا بتهوّر في الكود… ولا تضرب السيستم.

الكود بيبقى منظم ونضيف جدًا.​

وبيقلّل الـ Bugs، وبيخلي Maintenance سهلة.

مناسب لأي حجم سيستم​

سواء ERP، متجر كبير، CRM، أو حتى Microservices.

---

تخيل بقى تطبيق ده على الفاتورة! ​

الـ Event الرئيسي: invoiceCreated

الـ Listeners:
✓ checkInventory
✓ calculateTax
✓ createStockMovementReport
✓ calculateProfit
✓ updateDailyProfitReport
✓ sendNotification
✓ checkCustomerBalance
✓ createTaxReport
✓ updateProductMovementReport

كل ده بيشتغل اوتوماتيك من غير ما الكود يبقى أكوَّدة.

---

طيب لو سيستم كبير؟ استخدم Event Bus أو Message Broker ​

لو المشروع كبر، تقدر تطلع لمستوى أعلى:
• Kafka
• RabbitMQ
• Redis Pub/Sub
• NATS
ودي تعتبر Observer برضه بس على مستوى سيرفرات كاملة.

خلاصة الكلام ​

لو عايز تبني سيستم Backend قوي يستحمل Events كتير في نفس الوقت…
من غير ما يتكركب، أو يبقى اسباجيتي، أو يحصل انهيار مع أول تغيير…
استخدم Observer Pattern.

هو حل نظيف، عملي، وقابل للتطوير.
ومناسب جدًا للمشاريع الكبيرة اللي كل يوم بتكبر أكتر.

ابدأ صغير بـ EventEmitter…
وبعدين طوّر لكافكا أو RabbitMQ لما السيستم يكبر.

المهم…
متكتبش كل الكود في Function واحدة وتبقى كارثة