الحالة
معظم تكاملات التجارة الإلكترونية مباشرة: طلب مُقدَّم، مخزون مُخفَّض، بريد إلكتروني مُرسَل. أما PEAQ فمختلفة. حين يشتري العميل جهاز PEAQ Plunge، تحتاج عملية الشراء إلى تزويد ملف تعريف الجهاز في التطبيق الجوّال المرافق — نظام خلفي منفصل بواجهته الخاصة وكمون خاص وأوضاع فشل خاصة. النهج الساذج متزامن: تدفع الدفع واجهة برمجة الجهاز، تنتظر الرد، ثم تؤكد الطلب. المشكلة أن API الجهاز حين يكون بطيئاً أو غير متاح مؤقتاً، تنتهي مهلة الدفع. العملاء يرتبكون، وتخلق عمليات إعادة المحاولة طلبات مكررة. حللنا المشكلة ببنية قوائم انتظار غير متزامنة. نقطة نهاية الدفع تتولى شيئاً واحداً: تسجيل الطلب وإرجاع التأكيد في أقل من 300ms. يُنفَّذ تزويد الجهاز كوظيفة خلفية مع منطق إعادة المحاولة والتراجع الأسي وضمانات الأمان.
ما كان يجب أن يتغير
كان اكتمال الطلب يجب أن يُطلق تزويد الجهاز في واجهة خلفية جوّالة منفصلة — لكن استدعاء API ذاك قد يستغرق 2-5 ثوانٍ وكان يفشل أحياناً. التكامل المتزامن يعني انتهاء مهلة الدفع حين يكون API الجهاز بطيئاً. العملاء يرون تأكيدات ناقصة ويعيدون المحاولة في الدفع.
لقد تغيرت
فصل كامل بقوائم انتظار غير متزامنة: الدفع يسجل الطلب ويرجع فوراً. عامل خلفي يلتقط وظيفة التزويد، يستدعي API الجهاز مع إعادة المحاولة والتراجع الأسي، ويُعلّم الطلب كمُزوَّد عند النجاح. في حالة الفشل بعد المحاولات، يتلقى فريق الدعم تنبيهاً — لا العميل. صفر انتهاء مهلات منذ الإطلاق.
ما حصل عليه العميل
- 01 صفر انتهاء مهلات دفع — تزويد جهاز غير متزامن
- 02 عمال قوائع انتظار آمنون للإعادة مع تراجع أسي
- 03 قاعدة بيانات ثنائية اللغة يُحررها الموظفون
- 04 عقد API نظيف يفصل المتجر عن الواجهة الخلفية
