التحدّي
كان لدى العميل — منصة تقنيات تسويق / SEO في الجولة B — نقطة نهاية مزدحمة تجمع عشرات الآلاف من السجلّات لكل طلب. ومع نمو حسابات العملاء، انجرف زمن الاستجابة عند الشريحة المئوية 95 من نحو 300 مللي ثانية إلى نحو 800. وبدأ المستخدمون المكثّفون يشهدون توقّف لوحات المعلومات عن الاستجابة.
كان الفريق قد أضاف بالفعل التخزين المؤقت والتقسيم إلى صفحات. أمّا الاختناق المتبقّي فكان في مسار الاستعلام نفسه — ولم يكن بالإمكان تغيير المخطّط دون كسر التكاملات اللاحقة.
المنهجية
- حلّلنا أداء أكثر نقاط النهاية ازدحامًا بحمولات إنتاج واقعية. كانت ثلاثة استعلامات مسؤولة عن 80% من زمن الاستجابة.
- أعدنا كتابة مسار القراءة لاستخدام فهارس مركّبة ونسخة قراءة مطابقة (read replica)، مع تخزين مؤقت عبر Redis على عمليات البحث الأعلى تنوّعًا (cardinality).
- شغّلنا حركة ظل (shadow traffic) في الإنتاج لمدة أسبوعين قبل ترقية المسار الجديد.
- خفّضنا إنفاق البنية التحتية بنحو 30% عبر إزالة ذاكرات التخزين المؤقت المكرّرة في الذاكرة وضبط أحجام نُسخ الـ replica بما يناسبها.
النتيجة
- زمن الاستجابة عند الشريحة المئوية 95: نحو 800 مللي ثانية ← <300 مللي ثانية على المسار المزدحم
- معدّل المعالجة: أكثر من 100 ألف عملية يوميًا بشكل مستدام دون توسّع أفقي
- التكلفة: خفض بنسبة 30% في الإنفاق السحابي الشهري
- صفر تغييرات كاسرة على عقود الـ API العامة
الحزمة التقنية
Python · FastAPI · PostgreSQL · Redis · AWS ECS · Terraform · Grafana