الطلب يطرح سؤالًا وينتظر الجواب. أما الحدث فيعلن واقعة ويمضي.
تكاد كل قرارات التكامل تختصر في هذه الجملة — وتكاد كل بيئة يصعب تشغيلها أن تكون نتيجة تجاهلها. النمطان ليسا خصمين؛ فكل منهما يجيب عن سؤال مختلف. ويبدأ الألم حين يُلوى أحدهما ليؤدي عمل الآخر.
النمط ليس تفضيلًا تقنيًا. إنه وعد بشأن كيفية تعطّل نظامين معًا.
اختر نمط الطلب والاستجابة حين يعجز المستدعي عن المضي دون الجواب. واختر الحدث حين تهمّ الواقعة مستهلكين أكثر مما تستطيع تسميته اليوم.
ما الذي يعد به كل نمط فعلًا
الاستدعاء المتزامن يقرن التوافر
حين يستدعي النظام A النظامَ B وينتظر، يكون A قد ورث بصمت زمن تشغيل B وزمن استجابته ونوافذ صيانته. على مستوى استدعاء واحد، لا بأس. أما على عمق ثلاث قفزات، فأضعف نظام في السلسلة هو الذي يحدّد توافر الرحلة كلها — ولم يوافق أحد على ذلك.
الحدث يفكّ الارتباط بالزمن
يعلن المنتِج “تم توظيف موظف” أو “تم إنشاء طلب” أو “تم ترحيل قيد” — وينتهي دوره. أما المستهلكون فيعالجون بإيقاعهم الخاص، ويمكن إضافتهم دون المساس بالمنتِج، ويمكنهم إعادة التشغيل عند تعافيهم. والثمن: لا أحد ينتظر، فلا يعرف أحد فورًا إن كان ما بعدهم قد نجح.
الفشل هو موضع الاختلاف الحقيقي بين النمطين
الاستدعاء الفاشل يفشل بصوت عالٍ، في وجه المستدعي، لحظة السؤال — وهو مثالي حين ينتظر إنسان الجواب. أما الحدث الفاشل فيفشل بهدوء، لاحقًا، داخل طابور — وهو مثالي حين يجب أن يصمد التسليم أمام انقطاع، وخطير حين لا يملك أحد مراقبة الطابور.
الاختيار وفق الأبعاد التي تحسمه
يحمل SAP Integration Suite النمطين معًا — تدفقات Cloud Integration وواجهات API المُدارة من جهة، وقدرات شبكة الأحداث (event mesh) من جهة أخرى — بحيث يمكن اتخاذ القرار لكل واجهة على حدة لا لكل منصة.
المنظومة تحتاج إلى الاثنين — عن قصد
البيئات الواقعية مختلطة: المستخدم الذي يراجع بيانات حساب موظف يحتاج إلى جواب متزامن؛ أما عملية التوظيف التي أنشأت ذلك الموظف فكان ينبغي أن تكون حدثًا، لأن كشوف الرواتب وتزويد أنظمة تقنية المعلومات وإدارة الصلاحيات والتحليلات كلها معنيّة، ولا ينبغي لأي منها أن يعطّل معاملة التوظيف.
العلامة المنذرة هي التماثل التام. فالمنظومة التي يكون فيها كل شيء استدعاء API من نقطة إلى نقطة تكون قد أعادت غالبًا إنتاج التشابك الذي أرادت استبداله — مع سجلّات أفضل. أما المنظومة التي يكون فيها كل شيء حدثًا فتكتشف غالبًا أن بعض الأسئلة كانت تحتاج فعلًا إلى أجوبة.
تسمية التفاعل→سؤال أم واقعة؟→اختيار العقد→تصميم مسار الفشل أولًا
قواعد تصمد عند الاحتكاك بالإنتاج
- احسم لكل تفاعل، لا لكل مشروع. فالعملية الواحدة تحوي عادةً سؤالًا وعدة وقائع.
- اجعل كل مستهلك متكافئ الأثر (idempotent). فإعادة المحاولة وإعادة التشغيل ميزة في التكامل المرن لا حالة شاذة — ومعالجة الرسالة نفسها مرتين يجب أن تكون آمنة.
- امنح كل طابور مالكًا. فطابور الرسائل الميتة بلا مراقبة انقطاعٌ مؤجّل بمؤقّت.
- أصدر نسخًا من العقد، لا من قائمة المستهلكين. فجوهر الحدث أن مستهلك الغد لا يكلّف المنتِج شيئًا.
وجهة نظر VISCAP
دَين التكامل هو دَين التوافر. كل قفزة متزامنة تضيفها اليوم انقطاعٌ توقّع عليه بالمشاركة لاحقًا.
حين نراجع بيئة أنظمة، نقرأ قائمة الواجهات في ضوء سؤال واحد: من ينتظر مَن، وهل قرّر أحد ذلك عن قصد؟ وخريطة الانتظار غير المقصود — مهام دفعية متوقفة بانتظار استدعاءات حيّة، وواجهات مستخدم متوقفة بانتظار سلاسل من الخدمات — هي عادةً أسرع طريق إلى الاستقرار والسرعة معًا.
السؤال الذي يجب طرحه على كل واجهة جديدة
ليس “API أم حدث؟” أولًا — بل “إذا توقّف الطرف الآخر ساعةً كاملة، فماذا ينبغي أن يحدث هنا؟” أجب عن ذلك بصدق، وغالبًا ما يختار النمط نفسه بنفسه.