مصطلحات مهمة في عالم الـ System Design 💯 (١٠)
.
.
في البوست اللي فات تكلمنا عن Microservices وإزاي الـ Message Queues بتساعد الـ Services تتواصل مع بعض من غير ما كل Service تستنى التانية.
وده حل مشكلة مهمة داخل النظام.
لكن لسه عندنا مشكلة من ناحية تانية...
إحنا قسمنا النظام، وزودنا الـ Services، وخلينا التواصل بينهم مرن وسهل.
طيب إيه اللي هيحصل لو المستخدم نفسه بدأ يبعت عدد ضخم جدًا من الـ Requests؟
أو Bot قرر يضرب الـ API بتاعنا بآلاف الطلبات في الثانية؟
لو مفيش أي قيود، ممكن عدد بسيط من الـ Clients يستهلك معظم موارد النظام ويأثر على باقي المستخدمين.
———
📌 Rate Limiting
الـ Rate Limiting فكرته ببساطة إننا بنحدد عدد الـ Requests اللي Client معين يقدر يبعتها خلال فترة زمنية.
مثلًا، ممكن نقول إن كل User مسموح له بـ 100 Request في الدقيقة.
لو عدى الحد ده، الـ API يرفض الـ Requests الزيادة مؤقتًا ويرجع غالبًا:
HTTP 429 - Too Many Requests
ليه ده مهم؟
تخيل إن عندك API بتعمل Search، وفجأة User واحد أو Bot بدأ يبعت آلاف الـ Requests كل ثانية.
من غير Rate Limiting، الـ Requests دي ممكن تستهلك الـ CPU والـ Memory والـ Database Connections، وفي النهاية تأثر على كل المستخدمين.
فـ Rate Limiting مش بس وسيلة للحماية من الـ Abuse، لكنه كمان بيساعدنا نحافظ على استقرار النظام ونضمن إن الموارد متوزعة بشكل عادل.
لكن هنا ممكن تسأل...
هل لازم كل Service في النظام تعمل Rate Limiting بنفسها؟
مع وجود عشرات الـ APIs والـ Microservices، الموضوع هيبقى معقد.
———
📌 API Gateway
تخيل إن عندك نظام كبير فيه Services كتير:
- Users Service
- Orders Service
- Payments Service
- Notifications Service
بدل ما الـ Client يعرف كل Service موجودة فين ويتعامل معاها بشكل مباشر، ممكن نخلي فيه نقطة دخول واحدة قدام النظام كله.
النقطة دي اسمها API Gateway.
الـ Client يبعت الـ Request للـ Gateway، والـ Gateway يقرر يعمل إيه.
ممكن يتأكد إن المستخدم authenticated، يطبق Rate Limiting، يسجل الـ Request، وبعدها يوجهه للـ Service المناسبة.
يعني مثلًا:
Client → API Gateway → Orders Service
أو:
Client → API Gateway → Payment Service
وبكده الـ Client مش محتاج يعرف تفاصيل النظام الداخلية كلها.
والـ Gateway كمان بيكون مكان مناسب لتطبيق سياسات مشتركة على كل الـ APIs، زي Authentication وRate Limiting وLogging وRouting.
لكن لسه فيه مشكلة ممكن تحصل حتى مع وجود كل الحماية دي.
تخيل إن المستخدم ضغط زرار Pay، والـ Request وصل فعلًا للـ Payment Service...
لكن حصل Network Error قبل ما المستخدم يستلم الـ Response.
المستخدم مش عارف العملية نجحت ولا لا، فيضغط Pay تاني.
دلوقتي عندنا نفس العملية اتبعتت مرتين.
هل من الطبيعي إن المستخدم يتخصم منه الفلوس مرتين؟
———
📌 Idempotency
الـ Idempotency معناها إن تكرار نفس الـ Request أكتر من مرة ميغيرش النتيجة النهائية عن لو الـ Request اتنفذ مرة واحدة.
وده مهم جدًا في العمليات الحساسة زي الدفع وإنشاء الأوردرات.
خلينا نرجع لمثال الدفع.
المستخدم ضغط Pay، والـ Payment Service بدأت العملية.
لكن الـ Response ضاع بسبب مشكلة في الشبكة.
المستخدم ضغط تاني.
لو الـ System بيتعامل مع الـ Requests كأنهم عمليتين مختلفتين، ممكن يحصل Double Payment.
لكن لو الـ Request الأول كان مرتبط بـ Idempotency Key زي:
payment_12345
لما الـ Request التاني يوصل بنفس الـ Key، النظام يقدر يعرف إن العملية دي اتنفذت قبل كده.
بدل ما ينفذها مرة تانية، يرجع نفس النتيجة السابقة.
وبكده حتى لو حصل Retry أو المستخدم ضغط الزرار أكتر من مرة، العملية نفسها متتنفذش مرتين.
وده سبب إن الـ Idempotency مهمة جدًا في Distributed Systems، لأن الـ Network Failures والـ Retries حاجات طبيعية بتحصل في الأنظمة الموزعة.
———
💡 الخلاصة
النهارده وصلنا لآخر 3 مفاهيم في السلسلة:
• الـ Rate Limiting: تحديد عدد الـ Requests المسموح بيها خلال فترة معينة، علشان نحمي النظام من الـ Abuse والضغط الزائد.
• الـ API Gateway: نقطة دخول واحدة بتتعامل مع Requests قبل ما توصل للـ Microservices، وبتساعد في Authentication وRate Limiting وRouting وغيرها.
• الـ Idempotency: ضمان إن تكرار نفس الـ Request ميكررش تنفيذ العملية أكتر من مرة.
وبكده نكون تكلمنا عن أهم أجزاء الـ System Design، من أول الـ Client والـ Server، لحد الـ Databases والـ Caching والـ Microservices والـ Message Queues، ووصلنا في النهاية لحماية الـ APIs والتعامل مع الـ Retries.
———
#system_design
.
.
في البوست اللي فات تكلمنا عن Microservices وإزاي الـ Message Queues بتساعد الـ Services تتواصل مع بعض من غير ما كل Service تستنى التانية.
وده حل مشكلة مهمة داخل النظام.
لكن لسه عندنا مشكلة من ناحية تانية...
إحنا قسمنا النظام، وزودنا الـ Services، وخلينا التواصل بينهم مرن وسهل.
طيب إيه اللي هيحصل لو المستخدم نفسه بدأ يبعت عدد ضخم جدًا من الـ Requests؟
أو Bot قرر يضرب الـ API بتاعنا بآلاف الطلبات في الثانية؟
لو مفيش أي قيود، ممكن عدد بسيط من الـ Clients يستهلك معظم موارد النظام ويأثر على باقي المستخدمين.
———
📌 Rate Limiting
الـ Rate Limiting فكرته ببساطة إننا بنحدد عدد الـ Requests اللي Client معين يقدر يبعتها خلال فترة زمنية.
مثلًا، ممكن نقول إن كل User مسموح له بـ 100 Request في الدقيقة.
لو عدى الحد ده، الـ API يرفض الـ Requests الزيادة مؤقتًا ويرجع غالبًا:
HTTP 429 - Too Many Requests
ليه ده مهم؟
تخيل إن عندك API بتعمل Search، وفجأة User واحد أو Bot بدأ يبعت آلاف الـ Requests كل ثانية.
من غير Rate Limiting، الـ Requests دي ممكن تستهلك الـ CPU والـ Memory والـ Database Connections، وفي النهاية تأثر على كل المستخدمين.
فـ Rate Limiting مش بس وسيلة للحماية من الـ Abuse، لكنه كمان بيساعدنا نحافظ على استقرار النظام ونضمن إن الموارد متوزعة بشكل عادل.
لكن هنا ممكن تسأل...
هل لازم كل Service في النظام تعمل Rate Limiting بنفسها؟
مع وجود عشرات الـ APIs والـ Microservices، الموضوع هيبقى معقد.
———
📌 API Gateway
تخيل إن عندك نظام كبير فيه Services كتير:
- Users Service
- Orders Service
- Payments Service
- Notifications Service
بدل ما الـ Client يعرف كل Service موجودة فين ويتعامل معاها بشكل مباشر، ممكن نخلي فيه نقطة دخول واحدة قدام النظام كله.
النقطة دي اسمها API Gateway.
الـ Client يبعت الـ Request للـ Gateway، والـ Gateway يقرر يعمل إيه.
ممكن يتأكد إن المستخدم authenticated، يطبق Rate Limiting، يسجل الـ Request، وبعدها يوجهه للـ Service المناسبة.
يعني مثلًا:
Client → API Gateway → Orders Service
أو:
Client → API Gateway → Payment Service
وبكده الـ Client مش محتاج يعرف تفاصيل النظام الداخلية كلها.
والـ Gateway كمان بيكون مكان مناسب لتطبيق سياسات مشتركة على كل الـ APIs، زي Authentication وRate Limiting وLogging وRouting.
لكن لسه فيه مشكلة ممكن تحصل حتى مع وجود كل الحماية دي.
تخيل إن المستخدم ضغط زرار Pay، والـ Request وصل فعلًا للـ Payment Service...
لكن حصل Network Error قبل ما المستخدم يستلم الـ Response.
المستخدم مش عارف العملية نجحت ولا لا، فيضغط Pay تاني.
دلوقتي عندنا نفس العملية اتبعتت مرتين.
هل من الطبيعي إن المستخدم يتخصم منه الفلوس مرتين؟
———
📌 Idempotency
الـ Idempotency معناها إن تكرار نفس الـ Request أكتر من مرة ميغيرش النتيجة النهائية عن لو الـ Request اتنفذ مرة واحدة.
وده مهم جدًا في العمليات الحساسة زي الدفع وإنشاء الأوردرات.
خلينا نرجع لمثال الدفع.
المستخدم ضغط Pay، والـ Payment Service بدأت العملية.
لكن الـ Response ضاع بسبب مشكلة في الشبكة.
المستخدم ضغط تاني.
لو الـ System بيتعامل مع الـ Requests كأنهم عمليتين مختلفتين، ممكن يحصل Double Payment.
لكن لو الـ Request الأول كان مرتبط بـ Idempotency Key زي:
payment_12345
لما الـ Request التاني يوصل بنفس الـ Key، النظام يقدر يعرف إن العملية دي اتنفذت قبل كده.
بدل ما ينفذها مرة تانية، يرجع نفس النتيجة السابقة.
وبكده حتى لو حصل Retry أو المستخدم ضغط الزرار أكتر من مرة، العملية نفسها متتنفذش مرتين.
وده سبب إن الـ Idempotency مهمة جدًا في Distributed Systems، لأن الـ Network Failures والـ Retries حاجات طبيعية بتحصل في الأنظمة الموزعة.
———
💡 الخلاصة
النهارده وصلنا لآخر 3 مفاهيم في السلسلة:
• الـ Rate Limiting: تحديد عدد الـ Requests المسموح بيها خلال فترة معينة، علشان نحمي النظام من الـ Abuse والضغط الزائد.
• الـ API Gateway: نقطة دخول واحدة بتتعامل مع Requests قبل ما توصل للـ Microservices، وبتساعد في Authentication وRate Limiting وRouting وغيرها.
• الـ Idempotency: ضمان إن تكرار نفس الـ Request ميكررش تنفيذ العملية أكتر من مرة.
وبكده نكون تكلمنا عن أهم أجزاء الـ System Design، من أول الـ Client والـ Server، لحد الـ Databases والـ Caching والـ Microservices والـ Message Queues، ووصلنا في النهاية لحماية الـ APIs والتعامل مع الـ Retries.
———
#system_design
❤2
Forwarded from DevJobs
2027 Software Engineering Internship & New Grad Positions 🚀
https://github.com/speedyapply/2027-SWE-College-Jobs
https://github.com/speedyapply/2027-SWE-College-Jobs
GitHub
GitHub - speedyapply/2027-SWE-College-Jobs: 2027 SWE internship & new graduate job list updated daily
2027 SWE internship & new graduate job list updated daily - speedyapply/2027-SWE-College-Jobs