System Design

شركة Uber بتستعمل Docstore وهو عبارة عن قاعدة البيانات الموزعة بتاعتهم واللي مبنية على MySQL و Docstore بتخزن عشرات الـ PetaBytes من البيانات وبتخدم عشرات الملايين من ال Requests في الثانية.

لما نيجي نتكلم عن الأنظمة اللي بتركز على عمليات القراءة أكتر من الكتابة، يعني الـ Systems اللي بيكون فيها نسبة قراءة للبيانات أكبر بكتير من نسبة الكتابة، ففيه شوية استراتيجيات ممكن نستخدمها عشان نحسن من الأداء.

تخيل معي أن مشروعاً برمجياً يتوسع وأصبح يعتمد على عدة أقسام، ووضعنا كل قسم في مستودعه الخاص على الـGitHub، وبالتالي أصبح كل قسم يتطلب تحديثاته واعتماداته الخاصة.

قامت GitHub بعمل Rollout لأكتر من Technical Upgrade وده بهدف التحسين من الـ Reliability والكفاءة الخاصة بعملية الـ Code Pushes. والـ Code Pushes هي أكيد واحدة من العمليات الشائعة والمتكررة اللي كلنا بنقوم بيها بشكل دوري.

الطريقة الشائعة واللي أغلبنا اتعرضلها عشان يقدر يولد Unique IDs عشان نستعملها في الـ Database ونميز الـ Rows كانت الـ UUID أو اللي بنسميه برضو GUID في منتجات Microsoft.

أحد أكبر المشاكل اللي ممكن نواجهها في تصميم الأنظمة الخاصة بالدفع , والمعاملات المالية هي أنك تدفع العميل أكتر من مرة, وعشان كده واحنا بنصمم Payment System محتاجين ناخد في الاعتبار ان عملية الدفع لازم نضمن انها هتتم مرة واحدة فقط لا غير.

مع مرور الوقت وزيادة حجم البيانات لا يمكن لجهاز واحد أن يتحمل كل هذه البيانات، فلا بد من زيادة عدد الأجهزة وتخزين البيانات عليها، وهنا يمكننا توزيع الـ Read Requests على أكثر من جهاز فبدلًا من قراءة البيانات من جهاز واحد فقط

إيقاف عمليات الـwrites على الـLeader Replica،  يؤدي بنا بعد وقت ما إلى مرحلة يصبح النظام فيها consistent؛ يعني ذلك أن استمرار عملية الـwrite لا تضمن لنا معرفة، بعد كم من الوقت سنصل إلى حالة الـconsistency، وهل سنصل لها أم لا

الـ Scalability احد اهم المفاهيم الاساسية في وقتنا الحالي , واللي مينفعش ما نكونش ملمين بيها .. واللي من خلاها بنفهم ازاي ندير تطور ونمور الـ Software بتاعنا.