0Pricing
System Design Basics for Backend Developers · Leçon

Limitation et régulation du débit

Apprenez comment la limitation du débit protège les systèmes contre les abus et la surcharge, notamment avec les algorithmes du seau de jetons et de la fenêtre glissante.

Limitation et régulation du débit est une leçon System Design Basics for Backend Developers gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage System Design Basics for Backend Developers, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours System Design Basics for Backend Developers comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

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

Questions Fréquemment Posées

La leçon « Limitation et régulation du débit » est-elle gratuite ?

Oui — le texte complet de « Limitation et régulation du débit » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours System Design Basics for Backend Developers, passe à CoddyKit PRO. Le cours System Design Basics for Backend Developers comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Limitation et régulation du débit » ?

Apprenez comment la limitation du débit protège les systèmes contre les abus et la surcharge, notamment avec les algorithmes du seau de jetons et de la fenêtre glissante. Tu pratiques System Design Basics for Backend Developers avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer System Design Basics for Backend Developers ?

Aucune expérience préalable n'est requise. System Design Basics for Backend Developers sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Limitation et régulation du débit » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon System Design Basics for Backend Developers ?

Oui. Chaque leçon System Design Basics for Backend Developers inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Authentification et autorisation
  2. Chiffrement des données et confidentialité
  3. Protection contre les attaques DDoS et pare-feu
  4. Limitation et régulation du débit
← Retour à System Design Basics for Backend Developers