مفهوم الـ End-to-End Test 💯
.
.
خلال رحلتك في عالم البرمجة، ممكن تكون اشتغلت على Feature كبيرة، وكنت متأكد إن الـ code شغال زي الفل. وكتبت Unit Tests، وكل الـ functions بتـرجّع اللي المفروض ترجعه. بعد كده جربت الـ app بإيدك، كل حاجة ماشية حلو… بس لما رفعت الكود على الـ staging أو الـ production، فجأة فيه حاجات وقعت ومش شغاله...
المشكلة هنا إن اللي أنت اختبرته مش كفاية... أنت اختبرت أجزاء صغيرة، لكن معملتش اختبار للرحلة كاملة من أول ما الـ user يفتح الـ app لحد ما يوصل لهدفه.
وهنا بييجي دور الـ End-to-End Testing (E2E)...
———
🎯 يعني إيه End-to-End Test؟
الـ End-to-End Test ببساطة هو نوع من أنواع الـ Testing اللي بيحاكي تصرفات الـ user الحقيقية.
بنختبر الـ system كـ “صندوق أسود” من غير ما نهتم بالتفاصيل الداخلية، إحنا بس عاوزين نتأكد إن الـ app بيشتغل زي ما الـ user متوقع بالضبط، من أول خطوة لآخر خطوة.
يعني بنبدأ من الـ UI، ونتفاعل مع الـ buttons والـ forms والـ links، وبنشوف هل الـ backend بيرد زي ما المفروض؟ هل الـ database اتحدثت؟ هل النتيجة اللي ظهرت للمستخدم منطقية؟
———
📌 إمتى تستخدم الـ E2E؟
- لو بتسلم Feature مهمة جدًا، زي عملية دفع أو تسجيل دخول.
- لو الـ app فيه flows معقدة أو steps كتير وبتعتمد على بعض.
- لو عاوز تتأكد إن الـ integration بين الـ frontend والـ backend شغال تمام.
- وقت الـ release، علشان تطمن إن الـ system ككل شغال سليم من الأول للآخر.
———
🛠 أشهر أدوات الـ End-to-End Testing
- الـ Cypress: سهل، واضح، بيشتغل على المتصفح، وبيخليك تـ debug بسهولة.
- الـ Playwright: سريع وبيدعم browsers كتير، وممتاز للـ automation.
- الـ Selenium: قديم وتقيل شوية، بس لسه ناس بتستخدمه عشان مرن وبيشتغل بلغات مختلفة.
———
⚙️ أمثلة على Scenarios ممكن نعملها E2E Test
- مستخدم بيسجل في الموقع، بيرجعله confirmation message.
- مستخدم بيدخل بيانات كريدت كارد وبتتم عملية الدفع.
- مستخدم بيعمل login وبيتنقل على الـ dashboard.
- مستخدم بيبعت فورم contact us وتوصله رسالة تأكيد.
———
💡 ليه الـ E2E Tests مهمة؟
- بتمنع الـ regressions اللي ممكن تحصل بعد تغييرات كبيرة.
- بتكشف bugs مش ممكن تكتشفها بالـ Unit أو الـ Integration tests.
- بتديك confidence إن الـ system ككل شغال زي ما المفروض.
- بتساعد الفريق كله (frontend, backend, QA) يكونوا مطمنين قبل أي release.
———
⚠️ بس خلي بالك...
الـ E2E Tests تقيلة في الـ execution، وبطيئة مقارنةً بالأنواع التانية.
فعشان كده بنكتب منها بس الـ critical flows، مش كل حاجة.
كمان أي تغيير بسيط في UI ممكن يكسرها… فلازم تكتبها بشكل كويس وقابل للصيانة.
———
💡 نصائح لو هتبدأ تكتب E2E Tests:
- ابني test لكل user journey مهمة.
- حاول تعزل الـ data اللي بتستخدمه في التست (استخدم mocks أو test accounts).
- حافظ على naming واضح وسهل في الـ tests.
- شغّلها في CI/CD pipeline عشان تمسك المشاكل قبل ما توصل للناس.
———
الـ E2E Testing هو خط الدفاع الأخير، اللي بيأكد إن كل حاجة ماشية تمام من منظور المستخدم.
وكمان هو اللي بيخليك ضامن إن الـ feature اللي تعبت فيها مش هتبوظ لما تطلع production.
———
#software_development
.
.
خلال رحلتك في عالم البرمجة، ممكن تكون اشتغلت على Feature كبيرة، وكنت متأكد إن الـ code شغال زي الفل. وكتبت Unit Tests، وكل الـ functions بتـرجّع اللي المفروض ترجعه. بعد كده جربت الـ app بإيدك، كل حاجة ماشية حلو… بس لما رفعت الكود على الـ staging أو الـ production، فجأة فيه حاجات وقعت ومش شغاله...
المشكلة هنا إن اللي أنت اختبرته مش كفاية... أنت اختبرت أجزاء صغيرة، لكن معملتش اختبار للرحلة كاملة من أول ما الـ user يفتح الـ app لحد ما يوصل لهدفه.
وهنا بييجي دور الـ End-to-End Testing (E2E)...
———
🎯 يعني إيه End-to-End Test؟
الـ End-to-End Test ببساطة هو نوع من أنواع الـ Testing اللي بيحاكي تصرفات الـ user الحقيقية.
بنختبر الـ system كـ “صندوق أسود” من غير ما نهتم بالتفاصيل الداخلية، إحنا بس عاوزين نتأكد إن الـ app بيشتغل زي ما الـ user متوقع بالضبط، من أول خطوة لآخر خطوة.
يعني بنبدأ من الـ UI، ونتفاعل مع الـ buttons والـ forms والـ links، وبنشوف هل الـ backend بيرد زي ما المفروض؟ هل الـ database اتحدثت؟ هل النتيجة اللي ظهرت للمستخدم منطقية؟
———
📌 إمتى تستخدم الـ E2E؟
- لو بتسلم Feature مهمة جدًا، زي عملية دفع أو تسجيل دخول.
- لو الـ app فيه flows معقدة أو steps كتير وبتعتمد على بعض.
- لو عاوز تتأكد إن الـ integration بين الـ frontend والـ backend شغال تمام.
- وقت الـ release، علشان تطمن إن الـ system ككل شغال سليم من الأول للآخر.
———
🛠 أشهر أدوات الـ End-to-End Testing
- الـ Cypress: سهل، واضح، بيشتغل على المتصفح، وبيخليك تـ debug بسهولة.
- الـ Playwright: سريع وبيدعم browsers كتير، وممتاز للـ automation.
- الـ Selenium: قديم وتقيل شوية، بس لسه ناس بتستخدمه عشان مرن وبيشتغل بلغات مختلفة.
———
⚙️ أمثلة على Scenarios ممكن نعملها E2E Test
- مستخدم بيسجل في الموقع، بيرجعله confirmation message.
- مستخدم بيدخل بيانات كريدت كارد وبتتم عملية الدفع.
- مستخدم بيعمل login وبيتنقل على الـ dashboard.
- مستخدم بيبعت فورم contact us وتوصله رسالة تأكيد.
———
💡 ليه الـ E2E Tests مهمة؟
- بتمنع الـ regressions اللي ممكن تحصل بعد تغييرات كبيرة.
- بتكشف bugs مش ممكن تكتشفها بالـ Unit أو الـ Integration tests.
- بتديك confidence إن الـ system ككل شغال زي ما المفروض.
- بتساعد الفريق كله (frontend, backend, QA) يكونوا مطمنين قبل أي release.
———
⚠️ بس خلي بالك...
الـ E2E Tests تقيلة في الـ execution، وبطيئة مقارنةً بالأنواع التانية.
فعشان كده بنكتب منها بس الـ critical flows، مش كل حاجة.
كمان أي تغيير بسيط في UI ممكن يكسرها… فلازم تكتبها بشكل كويس وقابل للصيانة.
———
💡 نصائح لو هتبدأ تكتب E2E Tests:
- ابني test لكل user journey مهمة.
- حاول تعزل الـ data اللي بتستخدمه في التست (استخدم mocks أو test accounts).
- حافظ على naming واضح وسهل في الـ tests.
- شغّلها في CI/CD pipeline عشان تمسك المشاكل قبل ما توصل للناس.
———
الـ E2E Testing هو خط الدفاع الأخير، اللي بيأكد إن كل حاجة ماشية تمام من منظور المستخدم.
وكمان هو اللي بيخليك ضامن إن الـ feature اللي تعبت فيها مش هتبوظ لما تطلع production.
———
#software_development
❤6
مصطلحات مهمة في عالم الـ System Design 💯 (٣)
.
.
في البوست اللي فات عرفنا إن الـ Client بعت الـ Request، والـ Server استقبله، وتكلموا مع بعض باستخدام HTTP/HTTPS.
لكن بمجرد ما الـ Request يوصل للسيرفر، ييجي سؤال مهم...
إزاي السيرفر يعرف المطلوب منه؟
يعني لما تضغط على زرار Login، أو تعمل Search، أو تفتح قائمة المنتجات... إيه اللي بيخلي كل Request يروح للمكان الصح؟
الإجابة هي إن كل وظيفة في التطبيق بيكون لها API.
———
📌 API
الـ API اختصار لـ Application Programming Interface.
الاسم ممكن يخض شوية، لكن الفكرة أبسط من كده بكتير.
تخيل إنك في مطعم.
أنت مش بتدخل المطبخ بنفسك علشان تطلب الأكل، فيه ويتر بياخد منك الطلب، يوصله للمطبخ، وبعدها يرجعلك بالأكل.
الويتر ده هو الـ API.
هو الوسيط بين الـ Client والـ Server.
الـ Client يبعت Request، والـ API يستقبله، يوصله للجزء المناسب في السيرفر، وبعدها يرجع Response.
علشان كده لما تسمع حد بيقول:
"اعمل API للـ Login"
فهو يقصد نقطة دخول يقدر الـ Client يبعتلها بيانات تسجيل الدخول، والسيرفر يتعامل معاها ويرجع النتيجة.
لكن...
هل كل الـ APIs بتشتغل بنفس الطريقة؟
الإجابة لا.
وأشهر طريقة موجودة حاليًا اسمها REST.
———
📌 REST
الـ REST مش لغة برمجة، ولا Framework.
ولكن هي مجموعة قواعد بتنظم شكل الـ APIs.
يعني بدل ما كل Backend Developer يخترع طريقة مختلفة، بقى فيه أسلوب متفق عليه يخلي أي Developer يفهم الـ API بسهولة.
مثلًا...
لو عايز تجيب كل المنتجات، غالبًا هتلاقي Endpoint زي:
ولو عايز تضيف منتج جديد:
ولو عايز تعدل منتج:
الفكرة إن كل حاجة بقت ماشية بنمط معروف.
وده السبب إن أغلب الـ APIs اللي بنتعامل معاها النهارده هي REST APIs.
لكن مع الوقت، بدأت تظهر مشكلة.
أوقات الـ Client بيحتاج جزء صغير من البيانات، والسيرفر يرجع بيانات أكتر بكتير من اللي محتاجها.
وأوقات تانية يحتاج بيانات من أكتر من API علشان يقدر يعرض شاشة واحدة.
ومن هنا ظهر مفهوم جديد.
———
📌 GraphQL
الـ GraphQL جه يحل المشكلة دي.
بدل ما السيرفر يقرر إيه البيانات اللي هترجع، الـ Client هو اللي يحدد بالضبط هو محتاج إيه.
يعني لو شاشة فيها اسم المستخدم وصورته بس.
مش لازم السيرفر يرجع الإيميل، ورقم التليفون، والعنوان، وتاريخ الميلاد، وباقي البيانات.
الـ Client يطلب الاسم والصورة فقط.
والسيرفر يرجع الاسم والصورة فقط.
وده بيقلل حجم البيانات اللي بتتنقل، وبيخلي بعض الشاشات أسرع، خصوصًا في التطبيقات الكبيرة.
لكن ده مش معناه إن GraphQL أحسن من REST في كل الحالات.
كل واحد له استخداماته، واختيار واحد منهم بيعتمد على طبيعة النظام اللي بتبنيه.
———
💡 الخلاصة
النهارده عرفنا إزاي السيرفر بيفهم المطلوب منه.
- الـ API: هي نقطة التواصل بين الـ Client والـ Server، وكل Feature في التطبيق غالبًا بيكون لها API.
- الـ REST: أسلوب شائع لبناء الـ APIs باستخدام قواعد وأنماط متفق عليها.
- الـ GraphQL: بيدي الـ Client حرية يحدد البيانات اللي محتاجها بالظبط، بدل ما يستقبل بيانات زيادة.
دلوقتي بقينا عارفين إزاي الـ Client يطلب البيانات من السيرفر.
لكن... السيرفر بيجيب البيانات دي منين أصلًا؟
وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Databases، وSQL vs NoSQL، وVertical Scaling.
———
#system_design
.
.
في البوست اللي فات عرفنا إن الـ Client بعت الـ Request، والـ Server استقبله، وتكلموا مع بعض باستخدام HTTP/HTTPS.
لكن بمجرد ما الـ Request يوصل للسيرفر، ييجي سؤال مهم...
إزاي السيرفر يعرف المطلوب منه؟
يعني لما تضغط على زرار Login، أو تعمل Search، أو تفتح قائمة المنتجات... إيه اللي بيخلي كل Request يروح للمكان الصح؟
الإجابة هي إن كل وظيفة في التطبيق بيكون لها API.
———
📌 API
الـ API اختصار لـ Application Programming Interface.
الاسم ممكن يخض شوية، لكن الفكرة أبسط من كده بكتير.
تخيل إنك في مطعم.
أنت مش بتدخل المطبخ بنفسك علشان تطلب الأكل، فيه ويتر بياخد منك الطلب، يوصله للمطبخ، وبعدها يرجعلك بالأكل.
الويتر ده هو الـ API.
هو الوسيط بين الـ Client والـ Server.
الـ Client يبعت Request، والـ API يستقبله، يوصله للجزء المناسب في السيرفر، وبعدها يرجع Response.
علشان كده لما تسمع حد بيقول:
"اعمل API للـ Login"
فهو يقصد نقطة دخول يقدر الـ Client يبعتلها بيانات تسجيل الدخول، والسيرفر يتعامل معاها ويرجع النتيجة.
لكن...
هل كل الـ APIs بتشتغل بنفس الطريقة؟
الإجابة لا.
وأشهر طريقة موجودة حاليًا اسمها REST.
———
📌 REST
الـ REST مش لغة برمجة، ولا Framework.
ولكن هي مجموعة قواعد بتنظم شكل الـ APIs.
يعني بدل ما كل Backend Developer يخترع طريقة مختلفة، بقى فيه أسلوب متفق عليه يخلي أي Developer يفهم الـ API بسهولة.
مثلًا...
لو عايز تجيب كل المنتجات، غالبًا هتلاقي Endpoint زي:
GET /productsولو عايز تضيف منتج جديد:
POST /productsولو عايز تعدل منتج:
PUT /products/1الفكرة إن كل حاجة بقت ماشية بنمط معروف.
وده السبب إن أغلب الـ APIs اللي بنتعامل معاها النهارده هي REST APIs.
لكن مع الوقت، بدأت تظهر مشكلة.
أوقات الـ Client بيحتاج جزء صغير من البيانات، والسيرفر يرجع بيانات أكتر بكتير من اللي محتاجها.
وأوقات تانية يحتاج بيانات من أكتر من API علشان يقدر يعرض شاشة واحدة.
ومن هنا ظهر مفهوم جديد.
———
📌 GraphQL
الـ GraphQL جه يحل المشكلة دي.
بدل ما السيرفر يقرر إيه البيانات اللي هترجع، الـ Client هو اللي يحدد بالضبط هو محتاج إيه.
يعني لو شاشة فيها اسم المستخدم وصورته بس.
مش لازم السيرفر يرجع الإيميل، ورقم التليفون، والعنوان، وتاريخ الميلاد، وباقي البيانات.
الـ Client يطلب الاسم والصورة فقط.
والسيرفر يرجع الاسم والصورة فقط.
وده بيقلل حجم البيانات اللي بتتنقل، وبيخلي بعض الشاشات أسرع، خصوصًا في التطبيقات الكبيرة.
لكن ده مش معناه إن GraphQL أحسن من REST في كل الحالات.
كل واحد له استخداماته، واختيار واحد منهم بيعتمد على طبيعة النظام اللي بتبنيه.
———
💡 الخلاصة
النهارده عرفنا إزاي السيرفر بيفهم المطلوب منه.
- الـ API: هي نقطة التواصل بين الـ Client والـ Server، وكل Feature في التطبيق غالبًا بيكون لها API.
- الـ REST: أسلوب شائع لبناء الـ APIs باستخدام قواعد وأنماط متفق عليها.
- الـ GraphQL: بيدي الـ Client حرية يحدد البيانات اللي محتاجها بالظبط، بدل ما يستقبل بيانات زيادة.
دلوقتي بقينا عارفين إزاي الـ Client يطلب البيانات من السيرفر.
لكن... السيرفر بيجيب البيانات دي منين أصلًا؟
وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Databases، وSQL vs NoSQL، وVertical Scaling.
———
#system_design
❤6
مصطلحات مهمة في عالم الـ System Design 💯 (٤)
.
.
في البوست اللي فات عرفنا إزاي الـ Client يطلب بيانات من السيرفر باستخدام APIs، سواء كانت REST أو GraphQL.
لكن فيه سؤال مهم جدًا…
السيرفر بيجيب البيانات دي منين؟
لما تفتح بروفايل مستخدم، أو تشوف قائمة المنتجات، أو تبحث عن أوردر معين، أكيد البيانات دي لازم تكون متخزنة في مكان ما.
وهنا يظهر دور الـ Database...
———
📌 Databases
الـ Database هي المكان اللي بنخزن فيه البيانات بشكل منظم.
بدل ما التطبيق يعتمد على الذاكرة فقط، بيخزن البيانات بشكل دائم في قاعدة بيانات علشان يقدر يرجع لها في أي وقت.
تخيل عندك متجر إلكتروني.
فيه منتجات، ومستخدمين، وأوردرات، وعمليات دفع.
كل المعلومات دي بتتخزن داخل الـ Database.
ولما المستخدم يطلب حاجة، السيرفر يروح يجيب البيانات من قاعدة البيانات ويرجع النتيجة.
لكن مش كل قواعد البيانات بتشتغل بنفس الطريقة.
وهنا ييجي السؤال اللي بيتكرر كتير في أي Interview…
SQL or NoSQL?
———
📌 SQL vs NoSQL
قواعد بيانات SQL بتكون منظمة في جداول وعلاقات واضحة بين البيانات.
زي مثلًا:
- جدول للمستخدمين
- جدول للطلبات
- جدول للمنتجات
والعلاقات بينهم بتكون محددة بشكل واضح.
أشهر الأمثلة:
- PostgreSQL
- MySQL
- SQL Server
أما NoSQL فبتكون أكثر مرونة.
ممكن تخزن البيانات على شكل Documents أو Key-Value أو Graphs، من غير ما تكون ملتزم بنفس شكل الجداول التقليدي.
أشهر الأمثلة:
- MongoDB
- Redis
- Cassandra
———
طيب أختار إيه؟
لو عندك بيانات مترابطة وعايز معاملات تضمن سلامة البيانات، غالبًا SQL هيكون مناسب.
لو شكل البيانات بيتغير باستمرار، أو محتاج مرونة أكبر في التوسع، ممكن NoSQL يكون اختيار مناسب.
لكن مع الوقت، حتى لو اخترت النوع المناسب، هتواجه مشكلة تانية…
المستخدمين بيزيدوا، والضغط على السيستم بيزيد...
———
📌 Vertical Scaling
تخيل إن عندك سيرفر واحد، وكل حاجة شغالة عليه.
وفجأة عدد المستخدمين زاد جدًا.
أبسط حل يخطر في بالك إنك تزود إمكانيات السيرفر نفسه.
وده اسمه Vertical Scaling أو Scale Up.
يعني بدل ما تغير النظام كله، بتقوي الجهاز الحالي.
الحل ده سهل وسريع في البداية، لكنه له حدود.
لأن في مرحلة معينة، مهما زودت إمكانيات السيرفر، هتوصل لأقصى قدرة ممكنة، وساعتها هتحتاج تفكر بطريقة مختلفة.
———
💡 الخلاصة
• الـ Database: المكان اللي بيتخزن فيه كل بيانات التطبيق.
• الـ SQL: قواعد بيانات منظمة بعلاقات واضحة بين الجداول.
• الـ NoSQL: قواعد بيانات مرنة تناسب البيانات المتغيرة والتوسع بسهولة.
• الـ Vertical Scaling: تقوية السيرفر الحالي بزيادة الـ CPU أو الـ RAM أو الـ Storage.
———
دلوقتي عرفنا أول طريقة للتعامل مع زيادة الضغط على السيستم.
لكن إيه اللي هيحصل لو السيرفر نفسه وصل لأقصى إمكانياته المسموح بها ومبقاش كافي لوحده؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Horizontal Scaling وLoad Balancer وDatabase Indexing.
———
#system_design
.
.
في البوست اللي فات عرفنا إزاي الـ Client يطلب بيانات من السيرفر باستخدام APIs، سواء كانت REST أو GraphQL.
لكن فيه سؤال مهم جدًا…
السيرفر بيجيب البيانات دي منين؟
لما تفتح بروفايل مستخدم، أو تشوف قائمة المنتجات، أو تبحث عن أوردر معين، أكيد البيانات دي لازم تكون متخزنة في مكان ما.
وهنا يظهر دور الـ Database...
———
📌 Databases
الـ Database هي المكان اللي بنخزن فيه البيانات بشكل منظم.
بدل ما التطبيق يعتمد على الذاكرة فقط، بيخزن البيانات بشكل دائم في قاعدة بيانات علشان يقدر يرجع لها في أي وقت.
تخيل عندك متجر إلكتروني.
فيه منتجات، ومستخدمين، وأوردرات، وعمليات دفع.
كل المعلومات دي بتتخزن داخل الـ Database.
ولما المستخدم يطلب حاجة، السيرفر يروح يجيب البيانات من قاعدة البيانات ويرجع النتيجة.
لكن مش كل قواعد البيانات بتشتغل بنفس الطريقة.
وهنا ييجي السؤال اللي بيتكرر كتير في أي Interview…
SQL or NoSQL?
———
📌 SQL vs NoSQL
قواعد بيانات SQL بتكون منظمة في جداول وعلاقات واضحة بين البيانات.
زي مثلًا:
- جدول للمستخدمين
- جدول للطلبات
- جدول للمنتجات
والعلاقات بينهم بتكون محددة بشكل واضح.
أشهر الأمثلة:
- PostgreSQL
- MySQL
- SQL Server
أما NoSQL فبتكون أكثر مرونة.
ممكن تخزن البيانات على شكل Documents أو Key-Value أو Graphs، من غير ما تكون ملتزم بنفس شكل الجداول التقليدي.
أشهر الأمثلة:
- MongoDB
- Redis
- Cassandra
———
طيب أختار إيه؟
لو عندك بيانات مترابطة وعايز معاملات تضمن سلامة البيانات، غالبًا SQL هيكون مناسب.
لو شكل البيانات بيتغير باستمرار، أو محتاج مرونة أكبر في التوسع، ممكن NoSQL يكون اختيار مناسب.
لكن مع الوقت، حتى لو اخترت النوع المناسب، هتواجه مشكلة تانية…
المستخدمين بيزيدوا، والضغط على السيستم بيزيد...
———
📌 Vertical Scaling
تخيل إن عندك سيرفر واحد، وكل حاجة شغالة عليه.
وفجأة عدد المستخدمين زاد جدًا.
أبسط حل يخطر في بالك إنك تزود إمكانيات السيرفر نفسه.
وده اسمه Vertical Scaling أو Scale Up.
يعني بدل ما تغير النظام كله، بتقوي الجهاز الحالي.
الحل ده سهل وسريع في البداية، لكنه له حدود.
لأن في مرحلة معينة، مهما زودت إمكانيات السيرفر، هتوصل لأقصى قدرة ممكنة، وساعتها هتحتاج تفكر بطريقة مختلفة.
———
💡 الخلاصة
• الـ Database: المكان اللي بيتخزن فيه كل بيانات التطبيق.
• الـ SQL: قواعد بيانات منظمة بعلاقات واضحة بين الجداول.
• الـ NoSQL: قواعد بيانات مرنة تناسب البيانات المتغيرة والتوسع بسهولة.
• الـ Vertical Scaling: تقوية السيرفر الحالي بزيادة الـ CPU أو الـ RAM أو الـ Storage.
———
دلوقتي عرفنا أول طريقة للتعامل مع زيادة الضغط على السيستم.
لكن إيه اللي هيحصل لو السيرفر نفسه وصل لأقصى إمكانياته المسموح بها ومبقاش كافي لوحده؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Horizontal Scaling وLoad Balancer وDatabase Indexing.
———
#system_design
❤7
مصطلحات مهمة في عالم الـ System Design 💯 (٥)
.
.
في البوست اللي فات تكلمنا عن Vertical Scaling، وإن أبسط حل لزيادة الضغط هو إننا نقوّي السيرفر الحالي...
لكن تخيل إن عندك تطبيق وعدد المستخدمين زاد جدًا، وكل ما تزود RAM أو CPU تلاقي الضغط بيرجع يزيد تاني.
في لحظة معينة هتوصل لأقصى قدرة ممكنة للسيرفر.
إيه الحل؟
———
📌 Horizontal Scaling
بدل ما نقوّي سيرفر واحد، نضيف سيرفرات جديدة.
يعني لو عندك سيرفر واحد عليه ضغط عالي، ممكن تخلي عندك 2 أو 5 أو 10 سيرفرات يشيلوا الحمل مع بعض.
وده اسمه Horizontal Scaling أو Scale Out.
تخيل مطعم فيه موظف واحد بيستقبل الطلبات.
لما الزحمة تزيد، بدل ما نجيبله مكتب أكبر، نجيب موظفين إضافيين يساعدوه.
نفس الفكرة بالضبط.
الميزة هنا إنك تقدر تزود عدد السيرفرات تدريجيًا حسب عدد المستخدمين.
لكن ظهر سؤال جديد…
لو عندي 10 سيرفرات، الـ Request يروح لمين فيهم؟
———
📌 Load Balancer
هنا ييجي دور الـ Load Balancer.
هو جهاز أو خدمة بتقف قدام كل السيرفرات، وأي Request جديد يوصله، يقرر يبعته لأي سيرفر.
يعني بدل ما المستخدم يختار بنفسه، الـ Load Balancer هو اللي يوزع الطلبات بشكل ذكي.
مثلًا:
- السيرفر الأول مشغول جدًا - ابعت الطلب لسيرفر تاني.
- سيرفر وقع أو فيه مشكلة - متبعتلوش أي Requests.
- عايز توزع الحمل بالتساوي - وزّع الطلبات على كل السيرفرات.
من غير Load Balancer، ممكن سيرفر واحد ينهار من الضغط بينما باقي السيرفرات فاضية.
وده سبب إن أي نظام قابل للتوسع تقريبًا بيستخدم Load Balancer بشكل أو بآخر.
لكن حتى بعد توزيع الحمل، فيه مشكلة تانية ممكن تبطّأ النظام…
———
📌 Database Indexing
تخيل إن عندك كتاب فيه 1000 صفحة، وعايز تدور على موضوع معين.
هل هتقرأ الكتاب كله صفحة صفحة؟
أكيد لا.
هتروح للفهرس الأول.
الـ Index في قاعدة البيانات بيعمل نفس الفكرة.
بدل ما الـ Database تفتش في كل الصفوف علشان تلاقي مستخدم أو أوردر معين، تستخدم الـ Index علشان توصل للبيانات بسرعة.
مثلًا لو بتبحث كتير باستخدام email، ممكن تعمل Index على العمود ده هيخلّي البحث أسرع بفرق كبير.
لكن خلي بالك، كل Index إضافي بياخد مساحة، وبيخلّي عمليات الكتابة أبطأ شوية، علشان كده بنعمل Index للأعمدة اللي عليها عمليات بحث كتيرة.
———
💡 الخلاصة
النهارده عرفنا إزاي الأنظمة الكبيرة بتتعامل مع زيادة عدد المستخدمين:
• الـ Horizontal Scaling: إضافة سيرفرات جديدة بدل تقوية سيرفر واحد.
• الـ Load Balancer: توزيع الـ Requests على السيرفرات بشكل ذكي.
• الـ Database Indexing: تسريع البحث داخل قاعدة البيانات باستخدام Indexes.
———
دلوقتي بقينا نقدر نشغّل أكتر من سيرفر ونوزّع الحمل بينهم.
لكن إيه اللي هيحصل لو قاعدة البيانات بقت كبيرة جدًا؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Replication و Sharding و Vertical Partitioning.
———
#system_design
.
.
في البوست اللي فات تكلمنا عن Vertical Scaling، وإن أبسط حل لزيادة الضغط هو إننا نقوّي السيرفر الحالي...
لكن تخيل إن عندك تطبيق وعدد المستخدمين زاد جدًا، وكل ما تزود RAM أو CPU تلاقي الضغط بيرجع يزيد تاني.
في لحظة معينة هتوصل لأقصى قدرة ممكنة للسيرفر.
إيه الحل؟
———
📌 Horizontal Scaling
بدل ما نقوّي سيرفر واحد، نضيف سيرفرات جديدة.
يعني لو عندك سيرفر واحد عليه ضغط عالي، ممكن تخلي عندك 2 أو 5 أو 10 سيرفرات يشيلوا الحمل مع بعض.
وده اسمه Horizontal Scaling أو Scale Out.
تخيل مطعم فيه موظف واحد بيستقبل الطلبات.
لما الزحمة تزيد، بدل ما نجيبله مكتب أكبر، نجيب موظفين إضافيين يساعدوه.
نفس الفكرة بالضبط.
الميزة هنا إنك تقدر تزود عدد السيرفرات تدريجيًا حسب عدد المستخدمين.
لكن ظهر سؤال جديد…
لو عندي 10 سيرفرات، الـ Request يروح لمين فيهم؟
———
📌 Load Balancer
هنا ييجي دور الـ Load Balancer.
هو جهاز أو خدمة بتقف قدام كل السيرفرات، وأي Request جديد يوصله، يقرر يبعته لأي سيرفر.
يعني بدل ما المستخدم يختار بنفسه، الـ Load Balancer هو اللي يوزع الطلبات بشكل ذكي.
مثلًا:
- السيرفر الأول مشغول جدًا - ابعت الطلب لسيرفر تاني.
- سيرفر وقع أو فيه مشكلة - متبعتلوش أي Requests.
- عايز توزع الحمل بالتساوي - وزّع الطلبات على كل السيرفرات.
من غير Load Balancer، ممكن سيرفر واحد ينهار من الضغط بينما باقي السيرفرات فاضية.
وده سبب إن أي نظام قابل للتوسع تقريبًا بيستخدم Load Balancer بشكل أو بآخر.
لكن حتى بعد توزيع الحمل، فيه مشكلة تانية ممكن تبطّأ النظام…
———
📌 Database Indexing
تخيل إن عندك كتاب فيه 1000 صفحة، وعايز تدور على موضوع معين.
هل هتقرأ الكتاب كله صفحة صفحة؟
أكيد لا.
هتروح للفهرس الأول.
الـ Index في قاعدة البيانات بيعمل نفس الفكرة.
بدل ما الـ Database تفتش في كل الصفوف علشان تلاقي مستخدم أو أوردر معين، تستخدم الـ Index علشان توصل للبيانات بسرعة.
مثلًا لو بتبحث كتير باستخدام email، ممكن تعمل Index على العمود ده هيخلّي البحث أسرع بفرق كبير.
لكن خلي بالك، كل Index إضافي بياخد مساحة، وبيخلّي عمليات الكتابة أبطأ شوية، علشان كده بنعمل Index للأعمدة اللي عليها عمليات بحث كتيرة.
———
💡 الخلاصة
النهارده عرفنا إزاي الأنظمة الكبيرة بتتعامل مع زيادة عدد المستخدمين:
• الـ Horizontal Scaling: إضافة سيرفرات جديدة بدل تقوية سيرفر واحد.
• الـ Load Balancer: توزيع الـ Requests على السيرفرات بشكل ذكي.
• الـ Database Indexing: تسريع البحث داخل قاعدة البيانات باستخدام Indexes.
———
دلوقتي بقينا نقدر نشغّل أكتر من سيرفر ونوزّع الحمل بينهم.
لكن إيه اللي هيحصل لو قاعدة البيانات بقت كبيرة جدًا؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Replication و Sharding و Vertical Partitioning.
———
#system_design
❤8
AI Engineering from Scratch 💯
503 lessons. 20 phases. Every algorithm built from raw math before a single framework gets imported.
https://aiengineeringfromscratch.com
#ai
503 lessons. 20 phases. Every algorithm built from raw math before a single framework gets imported.
https://aiengineeringfromscratch.com
#ai
Aiengineeringfromscratch
AI Engineering from Scratch | Free AI Engineering Course
542 lessons. 20 phases. Write the backprop, the tokenizer, the attention mechanism, and the agent loop by hand.
❤1
مصطلحات مهمة في عالم الـ System Design 💯 (٦)
.
.
في البوست اللي فات عرفنا إزاي نزود عدد السيرفرات باستخدام الـ Horizontal Scaling، وإزاي الـ Load Balancer بيوزع الـ Requests بينهم.
لكن مع الوقت، المشكلة الحقيقية غالبًا بتكون في قاعدة البيانات نفسها.
تخيل إن عندك ملايين المستخدمين، ومئات الملايين من الطلبات، وكل السيرفرات بتقرأ وتكتب في نفس الـ Database.
في مرحلة معينة هتلاقي إن قاعدة البيانات بقت هي المشكلة الأكبر والأهم...
وقتها بنبدأ نفكر إزاي هنحل المشكلة دي...
———
📌 Replication
أول حل هو إننا نعمل نسخ متعددة من قاعدة البيانات.
يبقى عندنا:
• Primary Database
تستقبل عمليات الكتابة (Write).
• Replica Databases
تستقبل عمليات القراءة (Read).
تخيل إن عندك مكتبة عليها زحمة.
بدل ما الناس كلها تقف على نسخة واحدة من الكتاب، بتعمل نسخ إضافية علشان عدد أكبر من الناس يقدر يقرأ في نفس الوقت.
وده بالضبط اللي بيحصل مع Replication.
الميزة إنك تقدر توزع عمليات القراءة على أكتر من Replica، فتخفف الضغط على الـ Primary Database.
لكن إيه اللي هيحصل لو حجم البيانات نفسه بقى ضخم جدًا، حتى النسخ المتعددة مش كفاية؟
———
📌 Sharding
هنا بنقسم البيانات نفسها.
بدل ما كل المستخدمين موجودين في قاعدة بيانات واحدة، ممكن نقسمهم على عدة قواعد بيانات.
كأن عندك ملف ضخم جدًا، فقسمته على عدة أدراج بدل ما تحطه كله في درج واحد.
الميزة إن كل Shard يشيل جزء من البيانات فقط، وبالتالي الضغط يتوزع.
لكن الـ Sharding بيضيف تعقيد أكبر، لأن التطبيق لازم يعرف البيانات المطلوبة موجودة في أي Shard.
———
📌 Vertical Partitioning
تخيل جدول مستخدمين فيه:
- الاسم
- الإيميل
- رقم التليفون
- الصورة
- العنوان
- إعدادات الحساب
- بيانات إضافية تانية…
مش كل الطلبات محتاجة كل الأعمدة دي.
فممكن نفصل البيانات الأساسية في جدول، والبيانات الأقل استخدامًا في جدول تاني.
وده اسمه Vertical Partitioning.
يعني بدل ما كل Query تقرأ جدول ضخم، تقرأ الجزء اللي محتاجاه فقط.
———
💡 الخلاصة
النهارده عرفنا 3 طرق مختلفة علشان نكبر قاعدة البيانات:
• الـ Replication: إنشاء نسخ متعددة من قاعدة البيانات لتوزيع عمليات القراءة.
• الـ Sharding: تقسيم البيانات على عدة قواعد بيانات مختلفة.
• الـ Vertical Partitioning: تقسيم الأعمدة داخل الجداول لتقليل حجم البيانات المقروءة في كل Query.
دلوقتي نقدر نتعامل مع قواعد بيانات ضخمة جدًا.
لكن… حتى مع كل التقسيم والنسخ دي، لسه فيه مشكلة ممكن تقتل الأداء:
إننا نروح نكلم قاعدة البيانات في كل Request.
وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Caching و Denormalization و CAP Theorem.
———
#system_design
.
.
في البوست اللي فات عرفنا إزاي نزود عدد السيرفرات باستخدام الـ Horizontal Scaling، وإزاي الـ Load Balancer بيوزع الـ Requests بينهم.
لكن مع الوقت، المشكلة الحقيقية غالبًا بتكون في قاعدة البيانات نفسها.
تخيل إن عندك ملايين المستخدمين، ومئات الملايين من الطلبات، وكل السيرفرات بتقرأ وتكتب في نفس الـ Database.
في مرحلة معينة هتلاقي إن قاعدة البيانات بقت هي المشكلة الأكبر والأهم...
وقتها بنبدأ نفكر إزاي هنحل المشكلة دي...
———
📌 Replication
أول حل هو إننا نعمل نسخ متعددة من قاعدة البيانات.
يبقى عندنا:
• Primary Database
تستقبل عمليات الكتابة (Write).
• Replica Databases
تستقبل عمليات القراءة (Read).
تخيل إن عندك مكتبة عليها زحمة.
بدل ما الناس كلها تقف على نسخة واحدة من الكتاب، بتعمل نسخ إضافية علشان عدد أكبر من الناس يقدر يقرأ في نفس الوقت.
وده بالضبط اللي بيحصل مع Replication.
الميزة إنك تقدر توزع عمليات القراءة على أكتر من Replica، فتخفف الضغط على الـ Primary Database.
لكن إيه اللي هيحصل لو حجم البيانات نفسه بقى ضخم جدًا، حتى النسخ المتعددة مش كفاية؟
———
📌 Sharding
هنا بنقسم البيانات نفسها.
بدل ما كل المستخدمين موجودين في قاعدة بيانات واحدة، ممكن نقسمهم على عدة قواعد بيانات.
كأن عندك ملف ضخم جدًا، فقسمته على عدة أدراج بدل ما تحطه كله في درج واحد.
الميزة إن كل Shard يشيل جزء من البيانات فقط، وبالتالي الضغط يتوزع.
لكن الـ Sharding بيضيف تعقيد أكبر، لأن التطبيق لازم يعرف البيانات المطلوبة موجودة في أي Shard.
———
📌 Vertical Partitioning
تخيل جدول مستخدمين فيه:
- الاسم
- الإيميل
- رقم التليفون
- الصورة
- العنوان
- إعدادات الحساب
- بيانات إضافية تانية…
مش كل الطلبات محتاجة كل الأعمدة دي.
فممكن نفصل البيانات الأساسية في جدول، والبيانات الأقل استخدامًا في جدول تاني.
وده اسمه Vertical Partitioning.
يعني بدل ما كل Query تقرأ جدول ضخم، تقرأ الجزء اللي محتاجاه فقط.
———
💡 الخلاصة
النهارده عرفنا 3 طرق مختلفة علشان نكبر قاعدة البيانات:
• الـ Replication: إنشاء نسخ متعددة من قاعدة البيانات لتوزيع عمليات القراءة.
• الـ Sharding: تقسيم البيانات على عدة قواعد بيانات مختلفة.
• الـ Vertical Partitioning: تقسيم الأعمدة داخل الجداول لتقليل حجم البيانات المقروءة في كل Query.
دلوقتي نقدر نتعامل مع قواعد بيانات ضخمة جدًا.
لكن… حتى مع كل التقسيم والنسخ دي، لسه فيه مشكلة ممكن تقتل الأداء:
إننا نروح نكلم قاعدة البيانات في كل Request.
وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Caching و Denormalization و CAP Theorem.
———
#system_design
❤4🔥1
Introducing Claude Opus 5.
It's a thoughtful and proactive model that comes close to the frontier intelligence of Fable 5 at half the price.
https://www.anthropic.com/news/claude-opus-5
.
.
#ai
It's a thoughtful and proactive model that comes close to the frontier intelligence of Fable 5 at half the price.
https://www.anthropic.com/news/claude-opus-5
.
.
#ai
Anthropic
Introducing Claude Opus 5
Opus 5 is a step change improvement for the Opus tier powering long-running agents while delivering improvements in coding and professional work.
❤2
What Is Micro Frontend Architecture.pdf
443.8 KB
What Is Micro Frontend Architecture?
.
.
A frontend System Design approach that structures a frontend application as a set of independent, self-contained feature modules, each responsible for a specific domain or functionality.
.
.
#architecture #frontend
.
.
A frontend System Design approach that structures a frontend application as a set of independent, self-contained feature modules, each responsible for a specific domain or functionality.
.
.
#architecture #frontend
❤2
7 Essential Data Structures for Coding Interviews.pdf
1.7 MB
7 Essential Data Structures for Coding Interviews 💯
.
.
1- Array
2- Linked List
3- Hash Table
4- Stack
5- Queue
6- Heap
7- Binary Search Tree
———
#dsa
.
.
1- Array
2- Linked List
3- Hash Table
4- Stack
5- Queue
6- Heap
7- Binary Search Tree
———
#dsa
❤9
Algorithms-CS101.pdf
1.1 MB
Algorithms are a set of instructions or steps designed to perform a specific task or to solve a particular problem.
They are essential in computer science for data processing, calculations, and other tasks.
———
#algorithms
They are essential in computer science for data processing, calculations, and other tasks.
———
#algorithms
❤4
مصطلحات مهمة في عالم الـ System Design 💯 (٧)
.
.
في البوست اللي فات عرفنا يعني إيه Replication و Sharding و Vertical Partitioning، وعرفنا إزاي نتعامل مع كميات ضخمة من البيانات.
لكن حتى بعد كل ده، فيه سؤال مهم...
هل كل Request لازم يروح للـ Database؟
تخيل إن الصفحة الرئيسية في موقعك بيدخلها مليون مستخدم في اليوم، وكلهم تقريبًا بيطلبوا نفس البيانات.
هل منطقي إننا في كل مرة نروح نسأل الـ Database عن البيانات دي من أول وجديد؟
أكيد لا...
لأن حتى أسرع Database لها حدود، وكل قراءة زيادة معناها ضغط أكبر، واستهلاك أعلى للموارد.
———
📌 Caching
الـ Cache عبارة عن مكان بنخزن فيه البيانات اللي بنستخدمها بشكل متكرر، بحيث لما حد يطلبها مرة تانية، نرجعها بسرعة بدل ما نروح لقاعدة البيانات.
لو فيه عندك بيانات ثابتة معظم الوقت، ومبيحصلش عليها تغييرات كتير، فمش منطقي إن كل Request يروح للـ Database.
أول Request لو البيانات مش موجودة في الـ Cache وده اسمه (Cache Miss)، يجيبها من الـ Database ويحفظها في الـ Cache، وبعدها الطلبات التالية تعمل Cache Hit.
وده واحد من أهم الأسباب اللي بتخلي التطبيقات تكون سريعة الاستجابة، وفي نفس الوقت بيقلل الضغط على قاعدة البيانات.
لكن استخدام الـ Cache مش بيحل كل المشاكل.
———
📌 Denormalization
فاكر لما تكلمنا عن SQL Databases؟
وقتها قلنا إننا بنقسم البيانات على جداول مختلفة، علشان نقلل تكرار البيانات ونحافظ عليها منظمة.
وده فعلًا أفضل تصميم في حالات كتير.
لكن مع زيادة عدد المستخدمين، ممكن تلاقي إنك كل مرة تعرض صفحة واحدة، محتاج تعمل Join بين 4 أو 5 جداول.
وده بيكلف قاعدة البيانات وقت ومجهود مع كل Request.
هنا بعض الأنظمة بتاخد قرار مختلف.
بدل ما تمنع تكرار البيانات، تسمح بتكرار جزء منها، مقابل إن القراءة تبقى أسرع.
يعني مثلًا، بدل ما كل مرة تجيب اسم المستخدم من جدول Users، ممكن تخزن اسمه داخل جدول Orders نفسه.
أيوه... البيانات بقت مكررة.
لكن في المقابل، بقيت تقدر تجيب بيانات الأوردر في Query واحدة، من غير Joins كتير.
وده اسمه Denormalization.
لكن ليه تمن.
لأن لو اسم المستخدم تغير، هتحتاج تحدثه في أكتر من مكان.
ومن هنا تبدأ تكتشف إن الـ System Design معظمه عبارة عن Trade-offs.
كل قرار بيحل مشكلة، لكنه في المقابل بيخلق تحديات جديدة.
———
📌 CAP Theorem
بعد ما بدأنا نستخدم أكتر من Database، وعملنا Replication و Sharding، كده إحنا دخلنا عالم الـ Distributed Systems.
وفي العالم ده، فيه سؤال مهم جدًا...
هل ينفع كل السيرفرات تشوف نفس البيانات، والنظام يفضل متاح للمستخدمين، حتى لو حصلت مشكلة في الشبكة؟
للأسف... لا.
وده بالظبط اللي بتشرحه CAP Theorem.
النظرية دي بتقول إن في الأنظمة الموزعة، لو حصل Network Partition، مش هتقدر تحقق كل المميزات في نفس الوقت.
في الحالة دي، لازم تختار بين Consistency و Availability، لأن Partition Tolerance أصبحت مفروضة عليك.
فهل الأهم إن كل المستخدمين يشوفوا نفس البيانات، حتى لو بعض الطلبات هتتأخر؟
ولا الأهم إن النظام يفضل شغال ويرد على المستخدمين، حتى لو بعض البيانات تكون لسه متحدثتش في كل السيرفرات؟
علشان كده هتلاقي إن مفيش Database أو Distributed System ينفع لكل السيناريوهات.
كل واحد معمول علشان يوازن بين احتياجات مختلفة.
———
💡 الخلاصة
النهارده عرفنا 3 مفاهيم مهمين جدًا في تحسين أداء الأنظمة:
• الـ Caching: تخزين البيانات المستخدمة باستمرار في مكان أسرع، لتقليل الضغط على قاعدة البيانات.
• الـ Denormalization: تكرار جزء من البيانات لتقليل الـ Joins وتسريع عمليات القراءة.
• الـ CAP Theorem: عند حدوث Network Partition، لازم تختار بين Consistency و Availability.
———
دلوقتي بقينا نعرف إزاي نخلي الوصول للبيانات أسرع.
لكن... التطبيقات مش بتتعامل مع بيانات بس.
إيه اللي بيحصل مع الصور، والفيديوهات، والملفات؟ وهل منطقي نخزنها كلها داخل قاعدة البيانات؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Blob Storage و CDN وكمان هنتكلم عن الـ WebSockets
———
#system_design
.
.
في البوست اللي فات عرفنا يعني إيه Replication و Sharding و Vertical Partitioning، وعرفنا إزاي نتعامل مع كميات ضخمة من البيانات.
لكن حتى بعد كل ده، فيه سؤال مهم...
هل كل Request لازم يروح للـ Database؟
تخيل إن الصفحة الرئيسية في موقعك بيدخلها مليون مستخدم في اليوم، وكلهم تقريبًا بيطلبوا نفس البيانات.
هل منطقي إننا في كل مرة نروح نسأل الـ Database عن البيانات دي من أول وجديد؟
أكيد لا...
لأن حتى أسرع Database لها حدود، وكل قراءة زيادة معناها ضغط أكبر، واستهلاك أعلى للموارد.
———
📌 Caching
الـ Cache عبارة عن مكان بنخزن فيه البيانات اللي بنستخدمها بشكل متكرر، بحيث لما حد يطلبها مرة تانية، نرجعها بسرعة بدل ما نروح لقاعدة البيانات.
لو فيه عندك بيانات ثابتة معظم الوقت، ومبيحصلش عليها تغييرات كتير، فمش منطقي إن كل Request يروح للـ Database.
أول Request لو البيانات مش موجودة في الـ Cache وده اسمه (Cache Miss)، يجيبها من الـ Database ويحفظها في الـ Cache، وبعدها الطلبات التالية تعمل Cache Hit.
وده واحد من أهم الأسباب اللي بتخلي التطبيقات تكون سريعة الاستجابة، وفي نفس الوقت بيقلل الضغط على قاعدة البيانات.
لكن استخدام الـ Cache مش بيحل كل المشاكل.
———
📌 Denormalization
فاكر لما تكلمنا عن SQL Databases؟
وقتها قلنا إننا بنقسم البيانات على جداول مختلفة، علشان نقلل تكرار البيانات ونحافظ عليها منظمة.
وده فعلًا أفضل تصميم في حالات كتير.
لكن مع زيادة عدد المستخدمين، ممكن تلاقي إنك كل مرة تعرض صفحة واحدة، محتاج تعمل Join بين 4 أو 5 جداول.
وده بيكلف قاعدة البيانات وقت ومجهود مع كل Request.
هنا بعض الأنظمة بتاخد قرار مختلف.
بدل ما تمنع تكرار البيانات، تسمح بتكرار جزء منها، مقابل إن القراءة تبقى أسرع.
يعني مثلًا، بدل ما كل مرة تجيب اسم المستخدم من جدول Users، ممكن تخزن اسمه داخل جدول Orders نفسه.
أيوه... البيانات بقت مكررة.
لكن في المقابل، بقيت تقدر تجيب بيانات الأوردر في Query واحدة، من غير Joins كتير.
وده اسمه Denormalization.
لكن ليه تمن.
لأن لو اسم المستخدم تغير، هتحتاج تحدثه في أكتر من مكان.
ومن هنا تبدأ تكتشف إن الـ System Design معظمه عبارة عن Trade-offs.
كل قرار بيحل مشكلة، لكنه في المقابل بيخلق تحديات جديدة.
———
📌 CAP Theorem
بعد ما بدأنا نستخدم أكتر من Database، وعملنا Replication و Sharding، كده إحنا دخلنا عالم الـ Distributed Systems.
وفي العالم ده، فيه سؤال مهم جدًا...
هل ينفع كل السيرفرات تشوف نفس البيانات، والنظام يفضل متاح للمستخدمين، حتى لو حصلت مشكلة في الشبكة؟
للأسف... لا.
وده بالظبط اللي بتشرحه CAP Theorem.
النظرية دي بتقول إن في الأنظمة الموزعة، لو حصل Network Partition، مش هتقدر تحقق كل المميزات في نفس الوقت.
في الحالة دي، لازم تختار بين Consistency و Availability، لأن Partition Tolerance أصبحت مفروضة عليك.
فهل الأهم إن كل المستخدمين يشوفوا نفس البيانات، حتى لو بعض الطلبات هتتأخر؟
ولا الأهم إن النظام يفضل شغال ويرد على المستخدمين، حتى لو بعض البيانات تكون لسه متحدثتش في كل السيرفرات؟
علشان كده هتلاقي إن مفيش Database أو Distributed System ينفع لكل السيناريوهات.
كل واحد معمول علشان يوازن بين احتياجات مختلفة.
———
💡 الخلاصة
النهارده عرفنا 3 مفاهيم مهمين جدًا في تحسين أداء الأنظمة:
• الـ Caching: تخزين البيانات المستخدمة باستمرار في مكان أسرع، لتقليل الضغط على قاعدة البيانات.
• الـ Denormalization: تكرار جزء من البيانات لتقليل الـ Joins وتسريع عمليات القراءة.
• الـ CAP Theorem: عند حدوث Network Partition، لازم تختار بين Consistency و Availability.
———
دلوقتي بقينا نعرف إزاي نخلي الوصول للبيانات أسرع.
لكن... التطبيقات مش بتتعامل مع بيانات بس.
إيه اللي بيحصل مع الصور، والفيديوهات، والملفات؟ وهل منطقي نخزنها كلها داخل قاعدة البيانات؟
ده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Blob Storage و CDN وكمان هنتكلم عن الـ WebSockets
———
#system_design
❤7