Fan-out vs Transactions: حل مشاكل التحويل

مشكلة غريبة في أنظمة التحويل: لما الـ Notification تسبق الفلوس! 💸
تخيل السيناريو ده 👇
يوصل للعميل إشعار إن الفلوس اتحولت…
بس في الحقيقة:

• الرصيد لسه متخصمش
• والفلوس موصلتش للطرف التاني

طبيعي جدًا يحصل خناقة بين الطرفين 😅
واحد شايف نفسه بعت… والتاني شايف نفسه متبعتلوش!

المشكلة دي مش نادرة، وبتحصل بسبب تصميم سيستم غلط مش Bug بسيط.

السبب الحقيقي: استخدام Fan-out بشكل خاطئ ⚠️​

خلينا نبسّط الفكرة 👇
في السيستم ده، لما يحصل Transaction (تحويل فلوس)
الـ Service بتعمل Publish Event
بعد كده يحصل حاجة اسمها Fan-out

يعني الحدث (Event) بيتوزع على كذا Service في نفس الوقت:

• Service تبعت Notification 📩
• Service تخصم الرصيد 💰
• Service تزود رصيد الطرف التاني 🔁

📌 كل ده بيحصل بالتوازي (Parallelism)

---

ليه Fan-out فكرة قوية؟ 💡​

الـ Fan-out Design Pattern له مميزات قوية جدًا:

• Performance عالي (كل حاجة بتحصل في نفس الوقت)
• Decoupling (كل Service مستقلة)
• سهل تزود Consumers جديدة
• مناسب جدًا للـ Systems الكبيرة (Scalable)

مثال بدون Fan-out:
UserService → NotificationService → EmailService → Analytics
📌 كله Sequential (واحدة بعد التانية)
مثال بـ Fan-out: كل Service تشتغل في نفس الوقت 🚀

---

طيب فين المشكلة؟ 🤔​

المشكلة مش في Fan-out نفسه… المشكلة في استخدامه في مكان غلط

1. مفيش Ordering واضح​

مفيش ضمان إن:

• خصم الرصيد يحصل الأول
• وبعده إضافة الرصيد
• وبعده Notification

❌ ممكن Notification توصل الأول
❌ والفلوس توصل بعد 10 دقايق!​

2. Debugging بقى كابوس 😵​

الـ Flow مش Linear يعني بدل ما تمشي خطوة خطوة:

• كل حاجة شغالة في نفس الوقت
• Logs متوزعة في كذا Service

📌 صعب جدًا تتبع المشكلة

3. مشكلة Duplication​

ممكن نفس الـ Event يتبعت مرتين و Consumer يعالجه مرتين

❌ يخصم 10,000 مرتين
❌ أو يكرر العملية​

---

الخطأ الأكبر: استخدام Fan-out في Core Business ❌​

التحويلات المالية محتاجة:

• Strong Consistency
• ترتيب واضح (Ordering)
• تنفيذ مرة واحدة بس (Exactly Once Execution)

📌 ودي حاجات Fan-out مش بيضمنها لوحده

---

Fan-out مكانه الصح فين؟ ✅​

Fan-out ممتاز في الحاجات دي:

• Notifications 📩
• Analytics 📊
• Logging 🧾

💡 يعني Side Effects مش العمليات الأساسية

---

الحل بدون ما تهد السيستم كله 🔥​

مش لازم ترجع لكل حاجة من الأول… تقدر تصلّح التصميم بشكل ذكي 👇

1. فصل أنواع الـ Events (Event Separation)​

مش كل Event ينفع يتعامل بنفس الطريقة
لازم تفرق بين:

• TransactionProcessing → Event داخلي
• TransactionCompleted → Event نهائي

📌 القاعدة الذهبية: متبعتش Notification غير بعد النجاح الكامل

2. استخدام Orchestrator أو Saga Pattern 🎯​

بدل العشوائية… خليك منظم
اعمل Service مسؤولة عن التحكم في الـ Flow:
خطوات التحويل:

1. خصم الرصيد
2. إضافة الرصيد
3. تأكيد العملية

بعد كده فقط: 👈 يتم نشر Event اسمه TransactionCompleted

مثال بسيط (Pseudo Code):

async function transferMoney(sender, receiver, amount) {
  await deductBalance(sender, amount);
  await creditBalance(receiver, amount);

  publishEvent("TransactionCompleted", {
    sender,
    receiver,
    amount
  });
}

📌 كده ضمنت الترتيب + النجاح

3. استخدام Fan-in لتجميع النتائج 🧠​

بعد ما كل Service تخلص شغلها:

• كل واحدة ترجع Status
• الـ Orchestrator يجمع النتائج

👈 لو كله نجح = Success
👈 لو في فشل = Rollback أو Retry
📌 ده اسمه Fan-in

---

الخلاصة المهمة جدًا 🎯​

لو بتشتغل على سيستم فيه Transactions:

❌ متستخدمش Fan-out بشكل مباشر
❌ متسيبش الـ Flow عشوائي​

​

✅ استخدم Orchestrator
✅ افصل بين Events
✅ خلّي Notification بعد النجاح فقط​

---

قاعدة لازم تتحفظ 🔥​

Fan-out ممتاز… بس مش للفلوس!
استخدمه في:

✔️ Analytics
✔️ Notifications
✔️ Logging​

ومتستخدموش في:

❌ Transactions
❌ Payments
❌ أي حاجة محتاجة Consistency عالي​

---

النهاية 👇​

التصميم الصح مش بس بيحل المشكلة… ده بيمنع مشاكل أكبر بكتير في المستقبل
💡 افتكر: أي سيستم بيتعامل مع فلوس = لازم يكون Predictable مش Parallel