- بواسطة x32x01 ||
ليه لازم تحمي الـ API من الـ Overload؟ 
تخيل إن عندك Endpoint بسيط اسمه search، وفجأة السيرفر وقع والـ CPU بقى 100% والـ Database بطّلت تستجيب. لما تراجع الـ Logs هتلاقي إن في مستخدم أو Bot بيبعت مئات الطلبات في الثانية لنفس الـ Endpoint.ده اللي بنسميه API Abuse أو Request Flooding، وده ممكن يوقع أي نظام مش محمي.
يعني إيه Rate Limiting؟ 
Rate Limiting ببساطة هو تحديد عدد الطلبات المسموح بيها لكل مستخدم خلال مدة زمنية معينة.مثلاً:
- 100 طلب في الدقيقة
- أو 1000 طلب في الساعة
لو المستخدم عدّى الحد، السيرفر يبدأ:
- يرفض الطلبات
- أو يأخرها
ليه بنحتاج Rate Limiting؟ 
- حماية السيرفر من الـ Overload
- منع الـ Bots أو Scripts اللي بتعمل Flooding
- ضمان Fair Usage بين كل المستخدمين
- حماية العمليات الحساسة زي:
- تسجيل الدخول Login
- استرجاع كلمة السر Password Reset
من هجمات Brute Force
أشهر طرق تطبيق Rate Limiting 
1) Fixed Window
تحدد مثلًا لكل IP:100 طلب لكل دقيقة
لو عدّى → نوقف الطلبات لحد الدقيقة الجديدة.
العيب: ممكن يظلم بعض المستخدمين في آخر لحظة من الدقيقة.
2) Sliding Window
أذكى من الـ Fixed.بيراقب الوقت الحقيقي بدل الدقيقة الكاملة.
يعني بيحسب عدد الطلبات خلال آخر X ثواني.
ده بيكون أكثر عدل وثبات.
3) Token Bucket / Leaky Bucket
الإستراتيجية اللي بتستخدمها أغلب الخدمات الكبيرة:- AWS
- Cloudflare
- Nginx
كل Request بيستهلك Token
ولو الوعاء فاضي → لازم تستنى
ده بيدي:
- أداء ثابت
- مرونة عالية
- تحكم أدق
أمثلة حقيقية للاستخدام 
| السيناريو | الليمِت المقترح | السبب |
|---|---|---|
| محاولات تسجيل الدخول Login | 5 محاولات في الدقيقة | حماية من Brute Force |
| Search API | Limit لكل IP | منع الـ Bots من استنزاف السيرفر |
| عمليات الدفع أو الإيميلات | Limit صغير جدًا | لأن التكلفة عالية |
| Public API | Limit ثابت لكل مستخدم | أول طبقة حماية أساسية |
الخلاصة 
Rate Limiting مش اختيار… ده جزء أساسي في أي API محترم.هو اللي:
- بيحافظ على استقرار النظام
- يمنع إساءة الاستخدام
- يضمن عدالة بين كل المستخدمين
- يحمي السيرفر حتى تحت الضغط
لو البوست وضّحلك الفكرة
شاركـه عشان غيرك ما يقعش في نفس المشكلة
وقول لنا في التعليقات:
هل حصل قبل كده إن API عندك وقع بسبب Flooding؟
