Rate Limiting و API Gateway
Rate Limiting: الگوریتم‌های Token Bucket و Sliding Window + نقش API Gateway در معماری مدرن
چرا محدود کنیم؟
- حفاظت: DDoS و سوءاستفاده — یک کاربر همه ظرفیت را نخورد!
- منصفانه: همه کاربران سهم عادلانه
- هزینه: API پولی — مصرف = پول!
- پایداری: جلوگیری از فشار بیش‌ازحد به پایین‌دست
الگوریتم‌های Rate Limiting
۱. Token Bucket — استاندارد
سطل با ظرفیت B توکن؛ با نرخ R توکن/ثانیه پر می‌شود. درخواست = یک توکن؛ سطل خالی = رد!
- ✓ اجازه «ترک» کوتاه (سطل پر = تا B درخواست پشت‌سرهم)
- ✓ نرخ میانگین کنترل‌شده
۲. Sliding Window Log
تایم‌استمپ همه درخواست‌ها؛ درخواست جدید: در پنجره ۶۰ ثانیه چندتا بود؟ > حد = رد.
- ✓ دقیق؛ ✗ حافظه زیاد (همه تایم‌استمپ‌ها!)
۳. Sliding Window Counter — عملی
دو پنجره (فعلی + قبلی) با وزن‌دهی زمانی — تقریب خوب بدون لاگ کامل!
۴. Fixed Window
«هر دقیقه حداکثر ۱۰۰» — ساده اما مشکل مرز: ۹۹ در آخر دقیقه + ۹۹ در اول بعدی = ۱۹۸ در ۲ ثانیه!
سطح‌های محدودیت
| سطح | مثال |
|---|---|
| IP | ۱۰۰۰ req/min هر IP |
| کاربر | ۱۰۰ req/min هر توکن |
| API | ۱۰ req/min برای endpoint سنگین |
| سراسری | محافظت پایین‌دست |
API Gateway — دروازه‌بان
نقطه ورود واحد APIها با وظایف:
- Rate Limiting (همین مبحث!)
- احراز هویت: چک توکن قبل از رسیدن به سرویس‌ها
- Routing: /users → سرویس A، /orders → B
- SSL، کش، تبدیل پروتکل
- متریک و لاگ مرکزی
مثال: Kong، AWS API Gateway، Nginx
نکته: پاسخ 429 (Too Many Requests) + هدر Retry-After = کلاینت خوش‌رفتار را خوشحال نگه دارید! و Rate Limit توزیع‌شده با Redis (شمارنده بین چند سرور مشترک).
جمع‌بندی
- Rate Limit = حفاظت + انصاف + هزینه
- Token Bucket: استاندارد انعطاف‌پذیر
- Sliding Window: دقیق؛ Fixed: ساده اما مرزدار
- API Gateway: دروازه با احراز + محدودیت + مسیریابی
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.