بناء بنية تحتية للتقنية المالية قابلة للتوسع: دروس من أكثر من 50 مليون معاملة

عندما تجاوز Project S 10 ملايين معاملة في ربعه الأول، علمنا أن القرارات المعمارية التي اتخذناها في الأيام الأولى إما ستحملنا للأمام أو ستصبح الجدران التي سنصطدم بها. هذه هي قصة كيفية هندستنا لبنية تحتية للتقنية المالية تتعامل الآن مع أكثر من 50 مليون معاملة بنسبة توافر 99.9% — والدروس التي تعلمناها على طول الطريق.

الأخطاء المبكرة التي ارتكبناها

كل فريق هندسي يبني بنية تحتية للتقنية المالية يرتكب أخطاء. أخطاؤنا جاءت مبكراً وكانت مفيدة.

بدأنا بمعمارية أحادية — خدمة كبيرة واحدة تتولى معالجة المدفوعات وإدارة السجلات ومصادقة المستخدمين وإرسال الإشعارات. عملت بشكل جيد عند 100,000 معاملة شهرياً. عند مليون، بدأنا نرى التشققات: استعلام قاعدة بيانات واحد بطيء كان بإمكانه تدهور سير المدفوعات بالكامل. ارتفاع في الإشعارات كان بإمكانه حجب تأكيدات الدفع.

الدرس الأول: في التقنية المالية، كل نظام فرعي حرج، ولا يمكنها مشاركة أنماط الفشل.

التحول المعماري: الخدمات الدقيقة المدفوعة بالأحداث

أعدنا البناء حول معمارية خدمات دقيقة مدفوعة بالأحداث. أصبح كل مجال — المدفوعات والسجل والامتثال والإشعارات — خدمة مستقلة تتواصل عبر ناقل أحداث. اخترنا Apache Kafka كعمودنا الفقري، ليس بسبب شعبيته، بل لخصائصه المحددة: ضمان ترتيب الرسائل داخل الأقسام وتخزين السجل الدائم والقدرة على إعادة تشغيل الأحداث للمصالحة.

قرارات التصميم الرئيسية:

خدمة معالجة المدفوعات: عديمة الحالة وقابلة للتوسع أفقياً. كل نسخة تتعامل مع معاملة من البدء إلى الترخيص. لا حالة مشتركة في الذاكرة. إذا فشلت نسخة في منتصف المعاملة، تلتقط نسخة أخرى من آخر نقطة تفتيش مستمرة.

خدمة السجل: المصدر الوحيد للحقيقة لجميع الأرصدة المالية. نفّذنا سجلاً يُلحق فقط — كل ائتمان وخصم هو سجل جديد، ليس تحديثاً. هذا الثبات كان غير قابل للتفاوض: يمنحنا مسار تدقيق كاملاً ويجعل المصالحة واضحة.

خدمة الامتثال: معالجة غير متزامنة لفحوصات مكافحة غسل الأموال والاحتيال. بالنسبة للمعاملات منخفضة المخاطر تحت حدود محددة، تعمل فحوصات الامتثال بعد الترخيص. بالنسبة للمخاطر العالية، تحجب بشكل متزامن. هذا النهج متعدد الطبقات خفّض متوسط زمن استجابة المعاملة من 800 ميلي ثانية إلى 120 ميلي ثانية.

استراتيجية قاعدة البيانات: فصل مسارات القراءة والكتابة

من أكثر القرارات تأثيراً كان فصل مسارات القراءة والكتابة بالكامل.

جميع الكتابات تمر عبر مجمع PostgreSQL الأساسي مع تكرار متزامن لنسخة احتياطية. القراءات — التي تمثل 80% من جميع عمليات قاعدة البيانات — تمر عبر نسخ القراءة بتسامح 50 ميلي ثانية لتأخر التكرار.

لبحث المعاملات واستعلامات الرصيد، أضفنا طبقة تخزين مؤقت Redis بمدة 30 ثانية. هذا وحده خفّض حمل قراءة قاعدة البيانات بنسبة 65%.

نفّذنا أيضاً مصدر الأحداث على مستوى البيانات: كل تغيير في حالة دورة حياة الدفع يُخزَّن كحدث غير قابل للتغيير. يمكن إعادة بناء الحالة الحالية لأي معاملة بإعادة تشغيل تاريخ أحداثها. كان هذا لا يُقدَّر بثمن لتصحيح نزاعات العملاء والتحقيقات التنظيمية.

التعامل مع ارتفاعات الزيارات بمقدار 50 مرة

منصات التقنية المالية تشهد ارتفاعات في الزيارات متوقعة وغير متوقعة. أيام صرف الرواتب ومدفوعات نهاية الربع والحملات الترويجية يمكن أن تنتج 50 مرة من الزيارات الطبيعية في غضون دقائق.

نهجنا جمع التوسع المسبق مع التوسع التلقائي التفاعلي:

• التوسع المسبق: نحلل الأنماط التاريخية للمعاملات ونتوسع 20 دقيقة قبل الذرى المتوقعة
• التوسع التلقائي التفاعلي: Kubernetes HPA يُشغَّل بمقاييس مخصصة — ليس فقط CPU، بل عمق قائمة انتظار المعاملات وزمن الاستجابة p95 للمعالجة
• قواطع الدائرة: كل استدعاء API خارجي (شبكات البطاقات والشركاء المصرفيين) له قاطع دائرة. إذا تدهور اعتماد، نفشل بسرعة ونضع في قائمة الانتظار لإعادة المحاولة بدلاً من الإمساك بالخيوط

النتيجة: حدث الزيارات الكبير الأخير لدينا (تكامل تجارة إلكترونية كبير يصبح مباشراً) أنتج ارتفاع 47 مرة في الزيارات. شهدنا صفراً من المعاملات الضائعة.

حقيقة توافر 99.9%

أهداف التوافر سهلة الكتابة. تحقيقها يتطلب انضباطاً صارماً في مجالين: ممارسات النشر وإدارة الاعتماد.

للنشر، نستخدم أزرق-أخضر مع إصدارات canary. الإصدارات الجديدة تستقبل 5% من الزيارات لمدة 30 دقيقة قبل الطرح الكامل. أي زيادة في زمن الاستجابة p99 تتجاوز 20% تُشغّل التراجع التلقائي.

للاعتمادات، نفترض أن كل نظام خارجي سيفشل. APIsشبكة البطاقات واتصالات الشريك المصرفي وموفرو KYC — كلهم خلف قائمة انتظار احتياطية محلية. عندما ينقطع اعتماد، تُوضع المعاملات في قائمة الانتظار محلياً ونعالجها بتراجع أسي مع استرداد الاعتماد. يرى المستخدمون تأخيراً طفيفاً في المعالجة، لا فشلاً.

ما كنا سنفعله بشكل مختلف

لو كنا نبدأ من الصفر، سنفعل ثلاثة أشياء في وقت أبكر:

1. تنفيذ التتبع الموزع من اليوم الأول. أضفنا OpenTelemetry بعد ستة أشهر، وإعادة بناء دورة حياة المعاملة من السجلات وحدها كلّفتنا مئات من ساعات الهندسة.

2. تحديد SLOs قبل كتابة الكود. هدف توافر 99.9% جاء من متطلب تجاري. كان يجب تصميم التنفيذ التقني حول هذا الهدف من السطر الأول من الكود.

3. الاستثمار في هندسة الفوضى في وقت أبكر. لم نُجرِ يوم GameDay الأول حتى الشهر الرابع. بحلول ذلك الوقت، كنا قد واجهنا بالفعل نمطَي فشل لم نُصمَّم لهما في الإنتاج.

الأرقام اليوم

• 50 مليون+ معاملة معالَجة
• توافر 99.9% على مدى 18 شهراً
• متوسط زمن استجابة المعاملة 120 ميلي ثانية (p50)
• زمن استجابة p99 يبلغ 380 ميلي ثانية في ذروة التحميل
• صفر أحداث فقدان بيانات

القرارات المعمارية المهمة في التقنية المالية ليست رائعة. إنها تتعلق بالاتساق على التوافر في الأماكن الصحيحة، وبافتراض الفشل في كل مكان، والحفاظ على مسار تدقيق يمكن للجهات التنظيمية والعملاء الوثوق به بالكامل.