System Design Basics for Backend Developers · درس

تحديد معدّل الطلبات وخنقها

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

الدرس 4 من 413 خطوة

تحديد معدّل الطلبات وخنقها درس مجاني في System Design Basics for Backend Developers على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في System Design Basics for Backend Developers، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة System Design Basics for Backend Developers 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

Why Rate Limit?

Rate limiting caps how many requests a client can make in a time window. It protects a system from abuse, accidental floods, and runaway clients.

Stops brute-force and scraping attacks
Ensures fair sharing among clients
Protects backends from overload

Rate Limiting vs Throttling

The terms overlap but differ slightly: rate limiting rejects requests over a hard cap, while throttling often slows or queues excess requests rather than rejecting them outright.

Fixed Window Counter

The simplest scheme counts requests in fixed time windows, e.g. 100 per minute. It is easy but has an edge problem: a client can send 100 at the end of one window and 100 at the start of the next — 200 in a few seconds.

limit = 100
window = '12:00:00-12:00:59'
count = 0
# reset count to 0 each new window

Sliding Window

A sliding window smooths the edge problem by weighting the previous window or tracking timestamps over a rolling interval. It gives a more accurate, fairer limit at the cost of more bookkeeping.

Token Bucket

The token bucket is the most popular algorithm. Tokens refill at a steady rate up to a capacity. Each request consumes a token; if the bucket is empty, the request is rejected. This allows short bursts while bounding the average rate.

import time
class Bucket:
    def __init__(self, cap, rate):
        self.cap = cap
        self.rate = rate
        self.tokens = cap
        self.last = time.time()
    def allow(self):
        now = time.time()
        self.tokens = min(self.cap, self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

b = Bucket(5, 1)
print([b.allow() for _ in range(7)])

Leaky Bucket

The leaky bucket processes requests at a fixed rate, queuing bursts and 'leaking' them out steadily. It smooths traffic into a constant outflow — good when the downstream needs a steady, predictable load.

Choosing the Limit Key

Decide what to limit on:

Per API key or user — fair per-account limits
Per IP — defends against anonymous abuse
Per endpoint — protects expensive operations

Often you combine several keys.

Communicating Limits

Tell clients their status with standard headers and the right status code, so well-behaved clients can back off.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1735689600

Distributed Rate Limiting

With many app servers, an in-memory counter per server is inconsistent. Use a shared store like Redis with atomic increments (or Lua scripts) so the limit is enforced globally across the fleet.

INCR rl:user:42
EXPIRE rl:user:42 60
# reject when value > limit

Rate Limiting and DDoS

Rate limiting complements DDoS protection. Application-layer limits stop a single abusive client, while edge and network defenses absorb large volumetric floods before they reach your servers. Defense in depth uses both.

Designing Good Limits

Set limits from real usage data, allow reasonable bursts, expose clear headers, and return 429 with Retry-After. Consider tiered limits — higher caps for paid plans, stricter ones for unauthenticated traffic.

Quick Check

Test your understanding of rate limiting.

أجب عليها في الدرس التفاعلي

Recap

You learned to protect systems with rate limiting:

Fixed window, sliding window, token bucket, and leaky bucket
Choose limit keys: per user, per IP, per endpoint
Return 429 with Retry-After and rate-limit headers
Use a shared store like Redis for distributed enforcement

البدء مجانًا

تعلم System Design Basics for Backend Developers مع معلم ذكاء اصطناعي — مجانًا

اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.

الدورات: 12
الدروس: 48

ابدأ التعلم مجانًا عرض الدورة الكاملة

الأسئلة الشائعة

هل درس «تحديد معدّل الطلبات وخنقها» مجاني؟

نعم — نص درس «تحديد معدّل الطلبات وخنقها» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة System Design Basics for Backend Developers، انتقل إلى CoddyKit PRO. تتضمن دورة System Design Basics for Backend Developers 4 دروس في المجموع.

ماذا ستتعلم في «تحديد معدّل الطلبات وخنقها»؟

تعلّم كيف يحمي تحديد معدّل الطلبات الأنظمة من إساءة الاستخدام والحمل الزائد، بما في ذلك خوارزميتا دلو الرموز والنافذة المنزلقة. تتمرن على System Design Basics for Backend Developers مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ System Design Basics for Backend Developers؟

لا تُشترط خبرة سابقة. System Design Basics for Backend Developers على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «تحديد معدّل الطلبات وخنقها»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس System Design Basics for Backend Developers هذا؟

نعم. كل درس في System Design Basics for Backend Developers يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى System Design Basics for Backend Developers