إرسال الأحداث متزامنًا أم غير متزامن لقرارات الاحتيال؟

تحتاج معظم أنظمة مكافحة الاحتيال إلى المسارين: المتزامن للحظة التي يجب أن يقرر فيها المنتج قبل الاستمرار، وغير المتزامن للحدث الذي تريد تقييمه أو إثراءه أو مراجعته دون انتظار العميل. حدد نمط كل حدث قبل الإطلاق بدل إضافة المسار الآخر لاحقًا أثناء معالجة حادثة تشغيلية.

السؤال الأهم في مراجعة التصميم ليس «أي الواجهتين أحدث؟»، بل «هل يستطيع العميل المتابعة قبل أن يصلنا القرار؟». إن كانت الإجابة لا فالمسار متزامن، وإن كانت نعم فيمكنك إرسال الحدث إلى طابور المعالجة.

المتزامن عندما يجب أن ينتظر الإجراء

استخدم POST /api/v1/events عندما تعتمد حالة المنتج التالية على ALLOW أو REVIEW أو BLOCK. هذه واجهة الأحداث المتزامنة، وتعيد النتائج نفسها بالأحرف الكبيرة المستخدمة في بقية هذه المقالة. ولا تعتمد على هذه القيم عند استخدام POST /api/v1/decisions/evaluate، فهذه الواجهة تحوّلها إلى approve وdeny وreview بحروف صغيرة. المدفوعات والسحوبات وإعادة تعيين كلمة المرور وتغييرات الملف عالية المخاطر مكانها المسار المتزامن، وكذلك أي إجراء يحرّك مالًا أو يمنح جلسة جديدة بعد خطوة تحقق مثيرة للشك.

POST /api/v1/events

طبّق القرار ضمن الطلب نفسه: ALLOW يكمل الإجراء، وBLOCK يوقفه ويعرض رسالة أعددت نصها مسبقًا، وREVIEW يضيف خطوة تحقق أو يعلّق التنفيذ ويفتح حالة. وإذا كنت تتجاهل القرار و«تقرر لاحقًا»، فأنت لا تحتاج إلى المتزامن أصلًا، بل إلى غير المتزامن مع Webhook، وقد أضفت مهلة انتظار إلى عملية الدفع دون داعٍ.

احفظ معرف الحدث أو القرار على سجل الدفعة أو الدخول أو الملف. فسيسأل الدعم عن سبب تعليق التحويل، وستسأل الهندسة عن القاعدة التي انطبقت، ولن تجد إجابة إذا بقي المعرّف في سجل مؤقت.

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

المعالجة غير المتزامنة عندما لا يتطلب الإجراء قرارًا فوريًا

استخدم POST /api/v1/events/async عندما يستطيع العميل إكمال الإجراء ويستطيع فريق العمليات مراجعته لاحقًا. ومن الاستخدامات المعتادة: تسجيلات الدخول منخفضة المخاطر، ومراقبة المحافظ، وإثراء بيانات التحليلات، والمسارات التي لا تحتاج إلى حالة إلا عند ظهور ما يثير الشك.

POST /api/v1/events/async

ستحصل على معرّف مهمة ونتيجة لاحقة، غالبًا عبر Webhook. لهذا تكون إعادة المحاولة وidempotency أهم على هذا المسار. مقالة إعادة محاولة webhooks تشرح الجانب التشغيلي للإرسال غير المتزامن. وإذا أرسلت الحدث إلى طابور المعالجة ثم أنشأت حالة جديدة مع كل تسليم، فسيوفر عليك غير المتزامن وقت الانتظار لكنه سيضاعف حجم قائمة المراجعة.

لا تستخدم غير المتزامن لعمليات السحب لمجرد أن إعادة المحاولة فيه أسهل؛ فالعميل يظن أن المال في طريقه، ثم يصل BLOCK بعد دقيقتين فتتحول العملية إلى مهمة تسوية. إذا كان الإجراء يغيّر الأرصدة أو صلاحيات الوصول فابدأ بالمتزامن.

كيف تختار لكل حدث

إذا كان العميل لا يستطيع المتابعة دون قرار فاختر المتزامن، وإذا كان فريق العمليات يستطيع المراجعة بعد وقوع الحدث فاختر غير المتزامن. وإذا كانت الأحداث تصل على دفعات كبيرة ولا تحتاج إلى قرار إلا لجزء منها فاختر غير المتزامن مع Webhooks. أما إذا كان الإجراء يحرّك مالًا أو يغيّر صلاحيات الوصول فابدأ بالمتزامن، ثم أضف إرسالًا غير متزامن للأحداث التي تريد سياقًا إضافيًا عليها.

يمكن أن تستخدم رحلة العميل النمطين لأحداث مختلفة: محاولة دفع متزامنة وحدث دخول غير متزامن. تستفيد قواعد سجل الجهاز من سياق الدخول، بينما ينتظر الدفع قراره الخاص فقط. لا ترسل الحدث نفسه مرتين بالنمطين، بل أعطِ كل حدث اسمًا مستقلًا واحفظ معرّفاته.

اختبر القاعدة الجديدة في وضع المراقبة قبل تفعيل BLOCK. نمط إرسال الأحداث ووضع التشغيل إعدادان مستقلان. يمكنك استدعاء POST /api/v1/events لكل دفعة، مع توجيه نتائج BLOCK إلى REVIEW داخل منتجك خلال الاختبار. تعيد نيزا القرار، ويحدد إعداد التشغيل متى يُطبَّق على العميل.

حقول الطلب كلها في دليل مراقبة الأحداث. وثّق اسم كل حدث ونمط إرساله واستجابة المنتج لـ REVIEW ومعرف الحدث المحفوظ.

لا تجعل العميل ينتظر إلا حين يغيّر القرار نتيجة يراها بنفسه، وكل ما عدا ذلك يمكن إرساله إلى طابور المعالجة. هذا هو الفرق كله، والباقي مجرد اختيار المسار الذي تستدعيه.