E Commerce Web Development

PEAQ Recovery — تجارة إلكترونية يُفعِّل فيها الشراء الأجهزة الفعلية

PEAQ Recovery International 2024 View live site

0 Checkout timeouts post queue implementation

<30s Device activation time after payment clears

<300ms Checkout response time regardless of device API

−91% Support tickets (order confusion) month 1 post-launch

تبيع PEAQ أجهزة تعافٍ بالغمر في الماء البارد تتصل بتطبيق جوّال مرافق. الشراء من الموقع ليس مجرد معاملة — بل يُطلق تزويد الجهاز في نظام منفصل. بنينا الجسر: قوائم انتظار غير متزامنة تضمن تفعيل الجهاز دون المساس بسرعة الدفع.

نظرة عامة على المشروع

عن هذا المشروع

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

التحدي

ما المشكلة التي واجهوها؟

كان اكتمال الطلب يجب أن يُطلق تزويد الجهاز في واجهة خلفية جوّالة منفصلة — لكن استدعاء API ذاك قد يستغرق 2-5 ثوانٍ وكان يفشل أحياناً. التكامل المتزامن يعني انتهاء مهلة الدفع حين يكون API الجهاز بطيئاً. العملاء يرون تأكيدات ناقصة ويعيدون المحاولة في الدفع.

Hardware-connected storefront — web meets app

Async order processing — zero checkout timeouts

حلنا

ما الذي بنيناه ولماذا

فصل كامل بقوائم انتظار غير متزامنة: الدفع يسجل الطلب ويرجع فوراً. عامل خلفي يلتقط وظيفة التزويد، يستدعي API الجهاز مع إعادة المحاولة والتراجع الأسي، ويُعلّم الطلب كمُزوَّد عند النجاح. في حالة الفشل بعد المحاولات، يتلقى فريق الدعم تنبيهاً — لا العميل. صفر انتهاء مهلات منذ الإطلاق.

ما الذي حققه العميل