المشكلة التي تحلها معمارية Event-Driven ليست ما تعتقد
معظم الشركات التي تأتيني تعتقد أن Event-Driven ستحل مشكلة النمو. لا تفعل. إنها تحل مشكلة التزامن بين الأنظمة المختلفة وتأخير تنفيذ العمليات المعقدة. فرق كبير.
عندما جاء عميلي بمشكلة الخادم المتوقف، كان عندهم — ببساطة — خادم ضعيف وقاعدة بيانات بطيئة. لم يكن عندهم أنظمة متعددة تحتاج تزامن، ولا عمليات معقدة تأخذ وقتاً. كانوا يحتاجون إضافة خادم وتحسين query الخاص بهم. حل بـ 5000 دينار، بدلاً من إعادة بناء بـ 200 ألف.
هذا الدرس لم يغادر رأسي. عندما يسأل عميل عن Event-Driven اليوم، أسأله أسئلة محددة قبل أي توصية.
السؤال الأول: هل عندك مشكلة توقيت أم مشكلة قوة؟
Event-Driven تلمع عندما تحتاج عمليات معقدة لا تحدث فوراً. عميل يضع طلباً، والنظام يحتاج: بريد تأكيد، إنشاء فاتورة، تحديث المستودع، إرسال إشعار للمبيعات. كل هذا يحدث بالتوازي، لا متسلسل. عميل آخر لا ينتظر انتهاء كل خطوة قبل رؤية رد النظام.
في الطريقة التقليدية (monolithic)، تحدث كل الخطوات في request واحد. وإذا فشل أي جزء، تفشل العملية كلها. مع Event-Driven، يأتي الحدث في queue، وكل خدمة تتعامل مع الجزء اللي يعنيها، في وقتها، بدون أن تعطل الجزء التاني.
لكن هذا يضيف تعقيداً هائلاً: debugging أصعب، الأخطاء المنتشرة صعب متابعتها، البنية البرمجية أعقد. إذا مشروعك ما يحتاج كل هذا، تحتاج معمارية أخف.
CQRS: قراءة وكتابة منفصلة لمن؟
CQRS (Command Query Responsibility Segregation) تعني فصل عمليات الكتابة عن عمليات القراءة. مثال: عميل يرسل طلب (Command). النظام يسجل الطلب، ويرسل إشعار. في نفس الوقت، dashboard المديرين يقرأ من قاعدة بيانات منفصلة محسّنة للقراءة السريعة.
لماذا؟ لأن الكتابة والقراءة لهما احتياجات مختلفة جداً. الكتابة تحتاج consistency. القراءة تحتاج سرعة. لو دمجتهما في قاعدة واحدة، تضطر تختار: أكون سريعة في الاثنين لا؟ بتختار تضحي.
في رأيي، معظم الشركات الخليجية لا تحتاج CQRS في السنتين الأولى من النمو. تحتاجها عندما dashboard تصير بطيئة حقاً رغم التحسينات، أو عندما الكتابات الثقيلة تبدأ تعطل القراءات. وقتها، تنقل جزء القراءة إلى نظام منفصل. بسيط.
لكن التنفيذ الكامل ليس بسيط. أنت تحتاج نظام event sourcing، قاعدة بيانات ثانية، آلية تزامن بينهما. كل ده يزيد السعر والتعقيد.
متى أختار معمارية خفيفة بدلاً من الحل الكامل؟
اختبر هذا الترتيب مع عملائي دائماً:
المرحلة الأولى: Monolith بسيط مع قاعدة بيانات واحدة
الأول سنة، سنتين. كود واحد، قاعدة واحدة. سهل deploy، سهل debug. تكلفة منخفضة. معظم الشركات الناشئة في الخليج هنا.
المرحلة الثانية: قراءة محسّنة فقط (Read Replica)
عندما dashboard تصير بطيئة، ضيف نسخة قراءة من قاعدتك. الكتابة على الأصلية، القراءة على النسخة. بسيط، خفيف، يحل 80% من مشاكل السرعة بـ 20% من التعقيد.
المرحلة الثالثة: Async Jobs للعمليات الثقيلة
بدل ما تشتغل عملية ثقيلة داخل request (ممكن تاخذ 30 ثانية)، رميها في queue. العميل يرجع رد فوراً. الشغل تم في الخلفية. أنت تحتاج job processor بسيط (Redis, RabbitMQ).
المرحلة الرابعة: Event-Driven كامل عند الضرورة
عندما الأنظمة تصير متعددة جداً وتحتاج تكلم بعضها بعض في الحقيقي، وقتها تستثمر. لا قبل.
رأيت شركات خليجية ناشئة تبني معمارية Event-Driven من اليوم الأول، والنتيجة: developer واحد ضايع يحاول يفهم architecture معقدة بدون حاجة فعلية لها. كانوا أفضل حال لو ركزوا على الفيتشر والعملاء، لا على infrastructure.
التكلفة: الساعات بتكلف أكثر من الخادم الإضافي
كم تكلفك Event-Driven؟ اسأل نفسك: كم developer شهر لبناء architect معقدة؟ كم للتطوير عليها؟ كم للصيانة على المدى الطويل؟
من تجربتي في قيادة مشاريع كويتية: بناء نظام Event-Driven صحيح يأخذ 4-6 أسابيع على الأقل (بفريق 3 developers). تكلفة الساعات وحدها: 30,000-50,000 دينار. ثم maintenance مستمرة. مقابل كده، إضافة خادم جديد وتحسينات بسيطة: 5,000 دينار، وتشتغل من اليوم الأول.
صراحة، معظم الشركات في الكويت والسعودية والإمارات بتختار الخيار التاني الأول. والقرار ده صحيح في 90% من الحالات.
متى تستحق التكلفة؟
فقط عندما الفائدة واضحة: عمليات معقدة تحتاج تزامن حقيقي، أو أنظمة منفصلة تحتاج تكلم بعضها بسرعة وموثوقية عالية. مثال: eCommerce كبيرة، شركة لوجستيات، أنظمة حكومية. شركة صغيرة بـ CRM وموقع؟ لا تحتاج.
CQRS مع Event-Driven: أم منفصل؟
الكثير يخلط بين الاثنين. Event-Driven architecture هي الطريقة اللي الأنظمة تكلم بعضها. CQRS هي الطريقة اللي قاعدة البيانات نفسها منظمة.
ممكن تعمل Event-Driven بدون CQRS. ممكن تعمل CQRS بدون Event-Driven. أحياناً تحتاج الاثنين معاً — لكن قليل.
مثال: شركة سوشيال ميديا. Event-Driven: post واحد يتوزع على ملايين الأجهزة (feed updates). CQRS: الكتابة سريعة (user يرسل post)، والقراءة محسّنة (feed loading). الاثنين مع بعضهم منطقي هنا.
لكن شركة نقابات أو وساطة عقار؟ عمليات أبطأ، حجم بيانات أقل، تعقيد أقل. Event-Driven وحده قد يكفي. أو حتى monolith بقراءة محسّنة يكفي.
السؤال الحقيقي: هل أنت حاجز فعلاً؟
الخطأ الأكبر: الاستثمار في معمارية advanced قبل ما تصير مقيد فعلاً. أنت تقيس بالبيانات الحقيقية، لا بالتوقعات.
قبل ما تسأل عن Event-Driven أو CQRS، اسأل:
- هل عندك مقاييس (metrics) واضحة لـ performance؟
- أين بالظبط الاختناقات (bottlenecks)؟ Database؟ API؟ Network؟
- هل جربت الحلول البسيطة: caching، indexing، query optimization؟
- كم عدد queries بالثانية؟ بالفعل وليس توقع.
لو أجابك العميل: 'ما عندي مقاييس'، أول خطوة: راقب. ما تبني architecture من غير بيانات. معظم المشاريع المتأزمة في الخليج ركبت حل بسيطة (caching مثلاً) وخلصوها.
ملاحظة أخيرة: الفريق أهم من الأدوات
معمارية Event-Driven قوية بس بفريق يفهمها. لو عندك فريق junior، تعقيدها بتصير عاني. عندي عميل استأجر 3 developers، اثنين منهم أول مرة يشتغلوا على event sourcing. ضاعوا لسهولة ستة أشهر.
بصراحة، أوصيك: بناء على حجم فريقك وخبرتهم، قد تكون معمارية بسيطة مع فريق قوي أفضل من معمارية advanced مع فريق ضعيف. الفريق ده بيقرر 70% من نجاح المشروع.