الحالة
يبريم علامة مجوهرات فاخرة تمتلك بوتيكات في أرجاء الشرق الأوسط، وعملاؤها لا يتقبّلون عبارة 'نعتذر، القطعة بيعت فعلاً في بوتيك دبي.' كان على منصة التجارة الإلكترونية أن تُفي بمعايير تليق بما تبيعه: دقة مخزون مطلقة، وصفر أخطاء في المعاملات، وتجربة شراء تعكس الجودة الفاخرة ذاتها التي يشعر بها العميل في المتجر. التحدي التقني الجوهري هو: بوتيكات يبريم تبيع في الوقت الفعلي. يمكن لمندوب مبيعات في الرياض إتمام صفقة على قطعة وضعها عميل في لندن في سلة الدفع. دون مزامنة مخزون فورية وحجز المخزون وقت الدفع، يُكمل الزبون في لندن الدفع — ثم يتلقى رسالة اعتذار. بنينا شيئين لمنع ذلك. أولاً، تكامل ERP الفوري: كل عملية بيع في البوتيك تُطلق webhook يُحدّث مخزون المتجر الإلكتروني في غضون ثوانٍ. ثانياً، قفل معاملات على مستوى قاعدة البيانات في تدفق الدفع نفسه.
ما كان يجب أن يتغير
مبيعات البوتيك تحدث في الوقت الفعلي، بشكل مستقل عن المتجر الإلكتروني. كان النظام السابق يُحدّث مخزون الويب بمزامنة كل 24 ساعة — مما يعني أن المنتجات قد تظهر متاحة أونلاين لمدة تصل إلى يوم بعد بيعها في المتجر. كان الإفراط في بيع المنتجات عالية القيمة واقعاً متكرراً أضر بعلاقات العملاء.
لقد تغيرت
تكامل ERP مدفوع بـ Webhook: أنظمة البوتيك تُطلق أحداثاً عند كل عملية بيع مكتملة، محدّثةً مخزون المتجر الإلكتروني في غضون ثوانٍ. قفل معاملات SELECT FOR UPDATE عند بدء الدفع — القفل على مستوى الصف يُحتجز طوال مدة المعاملة. محاولات الدفع المتزامنة على المنتج ذاته تفشل مبكراً (قبل الدفع) برسالة واضحة.
ما حصل عليه العميل
- 01 مستحيل فعلياً الإفراط في البيع — قفل DB على مستوى الصف
- 02 مزامنة ERP الفورية — مبيعات البوتيك تنعكس في ثوانٍ
- 03 واجهتا متجر عربية RTL وإنجليزية بنفس الجودة
- 04 تصميم API يُولي الأمان الأولوية للمعاملات الفاخرة
