Comment concevoir la limitation de débit (rate limiting) ?

Question

Accepted Answer

**La limitation de débit** restreint le nombre de requêtes qu'un client peut effectuer dans une fenêtre de temps — protégeant les systèmes des abus, des surcharges et assurant une utilisation équitable. C'est un composant courant de conception système, avec plusieurs algorithmes et considérations.

## Pourquoi c'est important

```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.
```

## Algorithmes de limitation de débit

```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)
```

## Considérations d'implémentation

```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
```

## Pourquoi c'est important

Comprendre comment concevoir la limitation de débit est précieux car c'est un **composant courant de conception système** pour protéger les systèmes et assurer une utilisation équitable, donc c'est une connaissance pratique importante.

La limitation de débit — restreindre le nombre de requêtes qu'un client peut effectuer dans une fenêtre de temps — répond à des besoins importants : **se protéger contre les abus** (prévenir les attaques comme le brute force, le scraping et les attaques DoS), **prévenir les surcharges** (protéger la stabilité du système), assurer une **utilisation équitable** (aucun client ne monopolise les ressources, supporter les limites par niveau comme gratuit vs payant), et contrôler les coûts.

Ces éléments font de la limitation de débit une exigence courante pour les APIs et services.

Comprendre les **algorithmes** et leurs compromis — **fenêtre fixe** (simple mais permettant les pics de limite), **fenêtre glissante** (plus lisse et plus précis), **token bucket** (permettant les pics contrôlés tout en limitant le débit moyen — populaire et flexible), et leaky bucket (lissage de la sortie) — est la connaissance clé en matière de conception, car le choix du bon algorithme affecte le comportement.

Comprendre les **considérations d'implémentation** est particulièrement important : gérer la **limitation de débit distribuée** (limites partagées entre plusieurs serveurs, utilisant couramment **Redis** pour les compteurs atomiques rapides partagés entre instances — car les limites par serveur ne fonctionnent pas dans les systèmes distribués), identifier les clients (par clé API, utilisateur ou IP), retourner des réponses claires (HTTP 429 avec en-têtes retry-after), choisir où l'appliquer (passerelle, équilibreur de charge ou application), et granularité (par utilisateur, par endpoint, par niveau).

Ces éléments reflètent la conception d'une limitation de débit qui fonctionne dans les vrais systèmes distribués.

La limitation de débit est un composant fréquemment nécessaire, apparaissant souvent dans les discussions et entretiens de conception système.

Comme la limitation de débit est un composant courant et important pour protéger les systèmes (contre les abus et les surcharges) et assurer une utilisation équitable, et comme la compréhension des algorithmes, de leurs compromis et surtout de l'implémentation distribuée (limites partagées via Redis) est importante pour bien la concevoir, comprendre comment concevoir la limitation de débit est une connaissance de conception système précieuse et pratiquement pertinente — un composant courant pour protéger les services et assurer une utilisation équitable, nécessitant la compréhension des algorithmes et de l'implémentation distribuée, et un sujet fréquemment abordé dans la conception système pour construire des systèmes robustes et protégés.