Phase 04 / 05

Distributed Systems

القمة في System Design. لما السيستم بتاعك بيشتغل على عشرات أو مئات السيرفرات، إزاي تخليهم يتفقوا.

Section 01

Microservices Architecture

من Monolith إلى مئات الـ services

السيناريو

بدأت بمشروع e-commerce صغير. كل الكود في application واحدة (Monolith). شغال تمام لما كان فيه 100 يوزر.

الموقع كبر. بقى فيه 100 ألف يوزر. الفريق كبر، 50 مهندس بيشتغلوا على نفس الـ codebase. كل deployment بياخد ساعتين، لازم كل الفريق ينتظر.

الحل؟ Microservices. نقسم التطبيق لـ services صغيرة، كل واحدة بتعمل حاجة محددة.

Monolith vs Microservices

Monolith

Application واحدة، codebase واحدة، deployment واحد.

✓ سهل في البداية

✓ Debugging أسهل

✓ مفيش network calls

✕ Deployment صعب لما يكبر

✕ Scaling محدود

✕ تقنية واحدة للكل

Microservices

عدة services صغيرة، كل واحدة لها codebase و database مستقلة.

✓ Scaling مستقل لكل service

✓ Deploy منفصل

✓ تقنيات مختلفة

✕ Complexity عالي جداً

✕ Network calls كتيرة

✕ Distributed transactions صعبة

القاعدة الذهبية: ابدأ بـ Monolith. لما السيستم يكبر فعلاً، حوّل لـ Microservices تدريجياً. مش العكس.

مثال عملي: E-commerce

نفس التطبيق في الـ 2 architectures:

Monolith

┌─────────────────────────┐
│   E-commerce App        │
│   ─────────────────     │
│   • Users module        │
│   • Products module     │
│   • Orders module       │
│   • Payments module     │
│   • Inventory module    │
│                         │
│   ↓                     │
│   One Database          │
└─────────────────────────┘

Microservices

┌──────────┐  ┌──────────┐  ┌──────────┐
│  Users   │  │ Products │  │  Orders  │
│ Service  │  │ Service  │  │ Service  │
│   ↓ DB   │  │   ↓ DB   │  │   ↓ DB   │
└──────────┘  └──────────┘  └──────────┘

┌──────────┐  ┌──────────┐
│ Payments │  │Inventory │
│ Service  │  │ Service  │
│   ↓ DB   │  │   ↓ DB   │
└──────────┘  └──────────┘

كل service مستقلة. ممكن فريق مختلف يشتغل عليها، بـ تقنية مختلفة، و deploy بشكل منفصل.

مبادئ تصميم Microservices

1. Single Responsibility

كل service بتعمل حاجة واحدة بس، و بتعملها كويس. مش كل service لها 100 endpoint.

2. Database per Service

كل service لها database خاصة بيها. مفيش services بتشارك نفس الـ DB. ده بيضمن الاستقلالية.

3. API Communication

الـ services بتتكلم مع بعض من خلال APIs (REST، gRPC، أو messages). مفيش direct database access.

4. Decentralized

كل service مستقلة في الـ deployment، الـ technology، و الـ team.

مشاكل Microservices

Microservices مش حل سحري. بييجي معاها تحديات حقيقية:

• Network Latency: كل API call بياخد وقت
• Distributed Transactions: لو محتاج تعدل في 3 services، لو واحد فشل، إيه يحصل؟
• Debugging: تتبع bug عبر 10 services صعب جداً
• DevOps Complexity: بدل deployment واحد، 50
• Data Consistency: البيانات مش مركزية

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

API Gateway

لما عندك 50 service، اليوزر مش هيكلم كل واحدة. بنحط API Gateway في النص.

الـ API Gateway هو entry point واحد لكل الـ services.

مهام الـ API Gateway

• Routing: يعرف كل request يروح لأنهي service
• Authentication: يتأكد من الـ token قبل ما يبعت للـ services
• Rate Limiting: يحمي الـ services من الـ abuse
• Aggregation: يجمع بيانات من عدة services في response واحد
• Caching: يـ cache الـ responses الشائعة

أشهر Gateways: Kong, AWS API Gateway, Apigee, Tyk

أسئلة انترفيو على القسم ده

القسم 1 / 6