الحالة
بنت Allbirds واحدة من أكثر علامات الأحذية المستدامة شهرة في العالم. كان على الواجهة الخلفية لتجارتها الإلكترونية أن تواكب هذه السمعة — سريعة وموثوقة ومتسقة بغض النظر عن حجم الزيارات أو البيئة. المشكلة التي استُدعينا لحلها كانت تفاوت زمن استجابة الدفع. في الأحوال الاعتيادية، كان الدفع جيداً. لكن عند ارتفاع الزيارات — إطلاق منتج أو ظهور إعلامي — كان يصبح غير قابل للتنبؤ. وقت استجابة الدفع عند P95 كان يقفز إلى 4-6 ثوانٍ. العملاء يغادرون والإيرادات تضيع. استخرجنا خطط تنفيذ الاستعلامات على مسار الدفع ووجدنا المشكلة: روابط متعددة الجداول عبر جداول المنتجات والمخزون والمتغيرات والأسعار دون فهارس مركّبة مناسبة. تحت التحميل المتزامن، تصبح هذه الروابط مسحاً كاملاً للجدول.
ما كان يجب أن يتغير
قفز زمن استجابة الدفع إلى 4-6 ثوانٍ تحت أحمال زيارات كان ينبغي أن تكون مُدارَة تماماً. أظهرت خرائط الحرارة وتسجيلات الجلسات تخلياً واضحاً عند خطوة الدفع خلال نوافذ الزيارات العالية. كافح الفريق الهندسي أيضاً مع تناقضات مستمرة بين بيئة الاختبار والإنتاج.
لقد تغيرت
مراجعة SQL لمسار استعلام الدفع بالكامل: حددنا 6 استعلامات مسؤولة عن 80% من التأخير. أضفنا فهارس مركّبة على الأعمدة عالية الانتقائية، وأعدنا كتابة 3 استعلامات بـ eager loading مناسب للقضاء على أنماط N+1، ونقلنا إرسال البريد الإلكتروني إلى قائمة انتظار الوظائف الخلفية. حوّلنا المنظومة الكاملة إلى Docker. استقر وقت استجابة الدفع تحت 1.2 ثانية.
ما حصل عليه العميل
- 01 الدفع باستمرار تحت 1.2 ثانية حتى في الذروة
- 02 فهارس مركّبة + eager loading على جميع المسارات الساخنة
- 03 منظومة Docker — لا مفاجآت بين الاختبار والإنتاج
- 04 وظائف خلفية تتولى البريد الإلكتروني وجميع العمليات غير المتزامنة
