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