كيف تصمم تحديد معدل الطلبات (Rate Limiting)؟

Question

Accepted Answer

**تحديد معدل الطلبات** يقيد عدد الطلبات التي يمكن للعميل تقديمها في نافذة زمنية معينة — مما يحمي الأنظمة من الإساءة والحمل الزائد ويضمن الاستخدام العادل. وهو مكون شائع في تصميم الأنظمة، مع عدة خوارزميات واعتبارات.

## سبب أهمية تحديد معدل الطلبات

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## خوارزميات تحديد معدل الطلبات

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## اعتبارات التنفيذ

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## لماذا يهم

فهم كيفية تصميم تحديد معدل الطلبات ذو قيمة لأنه **مكون شائع في تصميم الأنظمة** لحماية الأنظمة وضمان الاستخدام العادل، لذا فهو معرفة عملية مهمة.

تحديد معدل الطلبات — تقييد عدد الطلبات التي يمكن للعميل تقديمها في نافذة زمنية — يعالج احتياجات مهمة: **الحماية من الإساءة** (منع الهجمات مثل القوة الغاشمة والكشط وDDoS)، **منع الحمل الزائد** (حماية استقرار النظام)، ضمان **الاستخدام العادل** (عدم احتكار العميل للموارد، دعم حدود متدرجة مثل المجاني والمدفوع)، والتحكم في التكاليف.

هذه تجعل تحديد معدل الطلبات متطلباً شائعاً للواجهات البرمجية والخدمات.

فهم **الخوارزميات** والمقارنات بينها — **النافذة الثابتة** (بسيطة لكن تسمح بارتفاعات حدودية)، **النافذة المنزلقة** (أسلس وأكثر دقة)، **دلو الرموز** (السماح بارتفاعات متحكم بها مع تحديد معدل متوسط — شعبية ومرنة)، ودلو التسرب (تسييس الإخراج) — هو معرفة التصميم الأساسية، حيث أن اختيار الخوارزمية الصحيحة يؤثر على السلوك.

فهم **اعتبارات التنفيذ** مهم بشكل خاص: التعامل مع **تحديد المعدل الموزع** (الحدود المشتركة عبر خوادم متعددة، يتم عادة استخدام **Redis** للعدادات الذرية السريعة المشتركة عبر الحالات — حيث أن الحدود لكل خادم لا تعمل في الأنظمة الموزعة)، تحديد هوية العملاء (بواسطة مفتاح API أو المستخدم أو عنوان IP)، إرجاع استجابات واضحة (HTTP 429 مع رؤوس retry-after)، اختيار مكان تطبيقه (البوابة أو موازن الحمل أو التطبيق)، والدقة (لكل مستخدم، لكل نقطة نهاية، متدرجة).

هذه تعكس تصميم تحديد معدل الطلبات الذي يعمل في الأنظمة الموزعة الحقيقية.

تحديد معدل الطلبات مكون ضروري متكرر، يظهر غالباً في نقاشات تصميم الأنظمة والمقابلات.

حيث أن تحديد معدل الطلبات مكون شائع ومهم لحماية الأنظمة (من الإساءة والحمل الزائد) وضمان الاستخدام العادل، وحيث أن فهم الخوارزميات ومقارناتها وخاصة التنفيذ الموزع (الحدود المشتركة عبر Redis) مهم لتصميمها بشكل جيد، فإن فهم كيفية تصميم تحديد معدل الطلبات معرفة نظام-تصميم قيمة وعملية — مكون شائع لحماية الخدمات وضمان الاستخدام العادل، يتطلب فهم الخوارزميات والتنفيذ الموزع، وموضوع يتم مناقشته بشكل متكرر في تصميم الأنظمة لبناء أنظمة قوية ومحمية.