الحالة
zFloos منصة ERP سحابية ونقطة بيع تستخدمها آلاف الشركات في المملكة العربية السعودية — مطاعم وتجار تجزئة وشركات خدمات — كل منها بياناتها ومنتجاتها ومعاملاتها وتقاريرها الخاصة على بنية تحتية مشتركة. الإيجار المتعدد بهذا الحجم يخلق مشكلة أداء محددة: كل استعلام يحتاج إلى مصفاة نطاق المستأجر، والاستعلامات ذات النطاق المحدود غير المفهرسة بشكل جيد تصبح أبطأ أضعافاً مضاعفة مع نمو عدد المستأجرين. عند انضمامنا للمشروع، تجاوزت أوقات استجابة API عند P95 ثانيتين لاستعلامات لوحة التحكم — رقم كان يزداد سوءاً كل شهر. أجرينا مراجعة شاملة للاستعلامات عبر نقاط النهاية الأكثر استخداماً. الإجراء المتخَذ في الفهرسة وحده حقق تحسين أداء API بنسبة 30% مقيسة خلال 30 يوماً. بصورة منفصلة، كانت بنية مزامنة POS تُسبّب تأخيرات في جهة الطرفية. حين يُكمل الصراف معاملة، كانت الطرفية تنتظر إقراراً سحابياً قبل عرض شاشة النجاح. نقلنا مزامنة POS إلى قائمة انتظار غير متزامنة: الطرفية تؤكد محلياً، المزامنة تحدث في الخلفية.
ما كان يجب أن يتغير
كانت أوقات استجابة API تتدهور شهراً بعد شهر مع نمو عدد المستأجرين — نتيجة طبيعية لاستعلامات ذات نطاق محدود غير مفهرسة تصبح أبطأ على النطاق الواسع. كانت طرفيات POS تتجمد خلال فترات الازدحام لأن مزامنة السحابة كانت متزامنة: نجاح الطرفية كان مشروطاً بالإقرار السحابي.
لقد تغيرت
مراجعة كاملة للاستعلامات عبر جميع نقاط النهاية الرئيسية. استراتيجية فهارس مركّبة على tenant_id + الأعمدة الخاصة بالاستعلام — حققت تحسناً مقيساً بـ 30%. طبقة ذاكرة Redis المؤقتة على مجاميع لوحة التحكم مع TTL مطابق لإيقاع التحديث. مزامنة POS غير متزامنة بالكامل: الطرفية تؤكد محلياً، المزامنة في الخلفية مع ضمان التسليم.
ما حصل عليه العميل
- 01 تسريع API بـ 30% — تحسين خالص، دون أجهزة جديدة
- 02 طرفيات POS لا تنتظر إقرار السحابة
- 03 ذاكرة Redis المؤقتة للوحة التحكم مع TTL ذكي لكل نوع تقرير
- 04 عزل بيانات المستأجرين صحيح على مستوى الاستعلام
