بقلكم على شيء مهم في تصميم الأنظمة وخاصة المالية.
في شيء في معمارية البرمجيات اسمه الـ Traffic Spike.
مثلاً لو بنيت منصة مستشار آلي (Robo-advisor) أو نظام لإدارة المدفوعات مبني أنه يعالج 200 طلب في الثانية بكل استقرار. وفجأة وقت إطلاق حملة أو ذروة تداول هجم على النظام 300 طلب في نفس اللحظة.
طبعاً الحل السهل والجاهز والبديهي اللي بيفكر فيه الأغلبية هو تفعيل الـ Auto-scaling وإضافة Replicas عشان تستوعب الضغط.
بس الواقع أن هذا الحل هو الأسوأ لأنه بيحرق ميزانية الكلاود بشكل مرعب.
النظام ال resilience هو اللي يتنبأ بهذا الشيء ويمتص الصدمات بدون ما يكلف الشركة دولار واحد إضافي.
مثلاً
بدل ما نخلي كل الطلبات تضرب قاعدة البيانات وتسبب انهيارها. بيكون في عندنا queue layer بحيث تستقبل الطلبات المهولة في أجزاء من الملي ثانية والـ Worker يسحبها ويعالجها بمعدله الطبيعي والآمن.
طبعاً حتى ال front side المفروض يكون فيه قدر من الذكاء عشان سلامة تجربة العميل. زي مثلاً يكون في Interceptors تعالج خطأ 429 (Too Many Requests) بشكل ما يأثر على العميل وتطبق خوارزميةExponential Backoff وبدل ما تطلع للمستخدم رسالة مزعجة مثل النظام مشغول التطبيق يعرض واجهة تحميل تطمينية كأنه يقول جاري تأمين المعاملة. وفي الخلفية يعيد المحاولة بعد ثانية، ثم ثانيتين.
الطريقة ذي بتضمن مرونة النظام وسلاسة تجربة العميل ولسا في طرق أخرى تعالج مشكلة ال Traffic Spike.
ولو جربتوا في شغلكم طرق أخرى شاركوها معانا في التعليقات 👇
Original source
This content was originally published as a LinkedIn post. Open it in a new tab.