tgoop.com/the_developer_guide/5512
Last Update:
مفهوم الـ API Rate Limiting 💡
.
.
تخيل إن عندك Event ضخم وكل الناس هتدخل من باب واحد بس. لو كل الناس حاولت تدخل في نفس اللحظة، إيه اللي هيحصل؟ زحمة، فوضى، وممكن الـ Event يتلغي.
نفس الفكرة بتحصل مع أي API… لما عدد كبير جدًا من الـ Requests يوصل للسيرفر في نفس الوقت، الأداء بينهار، والـ Users بيبدأوا يحسوا إن الخدمة بطيئة أو مش شغالة.
هنا بيجي دور الـ API Rate Limiting، اللي هو ببساطة نظام بيحط حدود واضحة لعدد الـ Requests اللي أي مستخدم أو تطبيق يقدر يبعته في فترة زمنية محددة، عشان يضمن إن الخدمة تفضل مستقرة وسريعة لكل الناس.
———
🤔 ليه نعمل Rate Limiting؟
1- حماية الـ Server
لو الـ API استقبل عدد Requests أكتر من طاقته، ممكن يقع أو يشتغل ببطء شديد. الـ Rate Limiting بيحافظ على أداء السيرفر.
2- منع الـ Abuse
فيه ناس بتحب تجرب تبعت ملايين Requests بسرعة عشان تهاك أو تعمل Spam. الحدود دي بتوقفهم.
3- توزيع الـ Resources بطريقة مناسبة
لو فيه أكتر من عميل بيستخدم الـ API، مش معقول واحد منهم ياخد 90% من الـ Resources والباقي يتخانقوا مع بعض.
———
⚙️ إزاي نطبق الـ Rate Limiting؟
- الـ Fixed Window
بتحدد مثلًا 100 طلب في كل دقيقة. لو عديت العدد، هتاخد Error (غالبًا 429 Too Many Requests) لحد ما الدقيقة تخلص.
- الـ Sliding Window
نفس فكرة الـ Fixed Window بس أذكى شوية. بيحسب requests خلال آخر فترة زمنية متحركة بدل ما يقسم الوقت لمربعات ثابتة.
- الـ Token Bucket
عندك "جيب" فيه Tokens، كل Request بياخد Token. الـ Tokens بتتجدد بمعدل ثابت. لو الجيب فاضي، استنى لحد ما يتجدد.
- الـ Leaky Bucket
زي الصفيحة اللي فيها ثقب صغير بينقط Requests بمعدل ثابت، حتى لو جالك دفعة كبيرة فجأة.
———
💡 نصائح لو أنت بتبني API
- حدد معدل Requests معقول بناءً على قدرات السيرفر وعدد العملاء.
- استخدم Caching في الحاجات اللي مش محتاجة تتطلب من السيرفر كل مرة.
- خلي عندك خطة لتعامل خاص مع العملاء المهمين (Premium Users).
———
وفقكم الله لكل خير 🌿
BY DevGuide 🇵🇸
Share with your friend now:
tgoop.com/the_developer_guide/5512