مصطلحات مهمة في عالم الـ System Design 💯 (٩)
.
.
في البوست اللي فات وصلنا لمرحلة إن الـ Client والـ Server بقوا قادرين يتواصلوا بشكل لحظي باستخدام WebSockets.
وده حل مشكلة مهمة جدًا: إزاي السيرفر يبعت تحديث للـ Client في نفس اللحظة من غير ما الـ Client يفضل يسأل كل شوية "فيه حاجة جديدة؟"
لكن لسه عندنا سيناريو تاني.
إيه اللي يحصل لو Service محتاجة تبلغ Service تانية إن حاجة حصلت؟
مثلًا، لو المستخدم دفع أونلاين، نظام الدفع محتاج يبلغ الـ Backend بتاعنا إن عملية الدفع نجحت.
هل هنفضل نعمل Requests كل شوية ونسأل: "الدفع نجح ولا لا؟"
مش أفضل حل.
———
📌 Webhooks
الـ Webhook فكرته بسيطة جدًا.
بدل ما أنت تفضل تسأل Service تانية إذا حصل Event جديد، بتديها URL عندك، وتقول لها: "لما الحدث ده يحصل، ابعتيلي Request هنا."
خلينا ناخد مثال واضح.
لو المستخدم دفع عن طريق Stripe، بدل ما النظام بتاعك يفضل يسأل Stripe كل شوية:
"الدفع نجح؟"
منصة Stripe نفسها تبعتلك HTTP POST Request على الـ Webhook URL بتاعك أول ما عملية الدفع تنجح.
وده بيوفر Requests كتير وبيخلي التواصل بين الأنظمة أكثر كفاءة.
لكن تخيل إن التطبيق بقى كبير جدًا.
بدل ما يكون عندك Service واحدة، بقى عندك مجموعة Services زي الـ Payments و Orders و Inventory Shipping و Notifications...
هل منطقي كل الوظائف دي تفضل داخل نفس التطبيق وتتواصل مع بعض بشكل مباشر؟
———
📌 Microservices
في البداية، ممكن تبني التطبيق كله كـ Monolith.
يعني كل الخدمات اللي فوق دي تبقى موجودة في تطبيق واحد.
وده مش شيء سيئ، بالعكس، الـ Monolith ممكن يكون اختيار ممتاز جدًا لتطبيق صغير أو في بداية المشروع.
لكن مع نمو التطبيق، الكود بيكبر، والـ Dependencies بين الأجزاء بتزيد، وأي تغيير في جزء من النظام ممكن يأثر على أجزاء تانية.
فممكن نبدأ نقسم التطبيق إلى Services أصغر.
مثلًا:
• الـ Payment Service مسؤولة عن الدفع.
• الـ Order Service مسؤولة عن الأوردرات.
• الـ Inventory Service مسؤولة عن المخزون.
• الـ Notification Service مسؤولة عن الإشعارات.
كل Service تبقى مسؤولة عن جزء واضح من النظام، وتقدر تطور فيها وتعمل لها Deploy وتعمل لها Scaling بشكل مستقل.
لكن هنا تظهر مشكلة جديدة.
لو عندي عشرات الـ Services، وكل Service محتاجة تتواصل مع Service تانية، هل كل واحدة هتفضل تبعت HTTP Request للتانية وتستنى الرد؟
ممكن، لكن مش كل العمليات محتاجة Response فوري.
وأحيانًا لو Service واحدة بطيئة أو واقعة، مش منطقي نخلي باقي النظام كله يستناها.
وده بالضبط اللي بيخلينا نحتاج Message Queues.
———
📌 Message Queues
تخيل إن المستخدم عمل Checkout.
دلوقتي فيه كذا حاجة ممكن تحصل:
لازم نعمل Payment، ونحدّث Inventory، ونبعت Notification، وممكن نبدأ تجهيز الـ Shipping.
هل لازم الـ Order Service تستنى كل الخدمات دي تخلص واحدة واحدة قبل ما ترد على المستخدم؟
مش بالضرورة.
ممكن بدل كده تحط Message في Queue وتقول:
"فيه Order جديد محتاج يتعالج."
الـ Queue تحتفظ بالرسالة، والـ Service المسؤولة عن تنفيذ المهمة تاخدها لما تكون جاهزة.
يعني عندنا طرف بيبعت الرسالة اسمه Producer، وطرف بيستقبلها ويعالجها اسمه Consumer.
الميزة هنا إن الـ Services مش لازم تكون مرتبطة ببعض بشكل مباشر.
لو الـ Payment Service مشغولة، الرسائل تفضل في الـ Queue لحد ما تقدر تعالجها.
ولو حصل ضغط كبير، ممكن تزود عدد الـ Consumers علشان تعالج عدد أكبر من الرسائل في نفس الوقت.
وده بيخلي النظام Scalable و Fault Tolerant، وبيفصل الـ Services عن بعض بشكل أفضل.
من أشهر الأدوات اللي بتستخدم للفكرة دي Kafka و RabbitMQ و Amazon SQS.
———
💡 الخلاصة
النهارده عرفنا إزاي الـ Services المختلفة ممكن تتواصل مع بعض من غير ما كل حاجة تبقى مرتبطة بشكل مباشر:
• الـ Webhooks: الـ Service تبعتلك Notification لما Event معين يحصل، بدل ما تفضل تسألها كل شوية.
• الـ Microservices: تقسيم التطبيق الكبير إلى Services أصغر، كل واحدة مسؤولة عن جزء محدد.
• الـ Message Queues: وسيط بيخلي الـ Services تتواصل بشكل Asynchronous، بحيث الـ Producer يحط الرسالة والـ Consumer يعالجها لما يكون جاهز.
———
دلوقتي عندنا نظام فيه Services كتير، والـ Message Queue ساعدتنا نفصل بينهم ونمنع الضغط من الانتقال من Service للتانية.
لكن إيه اللي هيحصل لو Client بدأ يبعت آلاف الـ Requests في الثانية على الـ Public APIs بتاعتنا؟
هل هنسيبه يبعت براحتـه؟
أكيد لا.
وده اللي هنتكلم عنه في البوست الجاي مع Rate Limiting و API Gateway ونتعرف على مصطلح Idempotency.
———
#system_design
