Limites de taux et quotas

Les limites de taux et les quotas sont les mécanismes fondamentaux de la gestion de la demande de ressources partagées : CPU, réseau, OBD, files d'attente, API externes. L'objectif est l'équité (fairness), la prévisibilité des SLO et la protection contre les surtensions, les abus et les « noisy neighbor ».

1) Concepts de base

Rate limit : Limite l'intensité des requêtes/opérations (req/s, msg/min, octet/s).
Burst est un sursaut à court terme admissible au-dessus du taux moyen.
Quota est la limite de volume par fenêtre de temps (documents/24 heures, Go/mois).
Concurrency cap : Limite les opérations simultanées (requêtes/jobs simultanées).
Scope est le domaine d'application : per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Algorithmes de limitation

2. 1 Token Bucket (seau avec tokens)

Options : 'rate' (tokens/s), 'burst' (taille du seau).
Fonctionne comme un « crédit » : les tokens accumulés permettent des pics courts.
Convient aux API externes et aux demandes personnalisées.

2. 2 Leaky Bucket (seau coulant)

Il « purge » en douceur le flux à une vitesse constante.
Bon pour lisser le trafic vers les backend'am sensibles.

2. 3 Fixed/Sliding Window

Fenêtre fixe : simple, mais vulnérable au « changement de fenêtre ».
Sliding window : plus précisément, mais plus cher en informatique.

2. 4 GCRA (Generic Cell Rate Algorithm)

Équivalent Token Bucket en termes d'heure d'arrivée virtuelle.
Précis et stable pour les limiteurs distribués (état moins conflictuel).

2. 5 Concurrency Limits

Limiter les opérations simultanées.
Protège contre l'épuisement des pools de flux/connexions et « head-of-line blocking ».

3) Où appliquer les limites

A la frontière (passerelle L7/API) : barrière principale, panne rapide (429/503), contrôles bon marché.
Au sein des services : caps supplémentaires pour les opérations lourdes (exportations, rapports, transformations).
À la sortie des systèmes externes : limites individuelles sous tiers (anti-pénalité).
Sur les files d'attente/workers : fairness aux pools partagés.

4) Scoops et priorités (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware : VIP/Enterprise obtiennent plus de « burst » et de poids, mais ne cassent pas le SLO général.
Composition des limites : tolérance finale = 'min (global, régional, ténant, personnalisé, endpoint)'.

5) Quotas en volume

Quotas journaliers/mensuels : Documents/24 heures, GB/mois, messages/min.
Seuils doux/rigides : avertissements (80/90 %) et « stop dur ».
Roll-up : comptabilité par objet (tables, fichiers, événements) et « retrait » dans la facturation.

6) Limiteurs distribués

Exigences : faible latence, cohérence, résistance aux pannes, mise à l'échelle horizontale.

Synchronisation locale + probabilistic : seaux chardons locaux + synchronisation périodique.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding : clés de vue 'limit : {scope} : {id} : {window}' avec une distribution uniforme.
Clock skew : Stockez la « vérité » sur le serveur du limiteur, pas sur les clients.
Idempotence : les clés « operations » (Idempotency-Key) réduisent les faux débits.

7) Anti-abyse et protection

Per-IP + device fingerprint pour les endpoints publics.
Proof-of-Work/CAPTCHA en cas d'anomalies.
Slowdown (throttling) au lieu d'échouer complètement lorsque l'UX est plus important (indices de recherche).
Limites adaptatives : abaissement dynamique des seuils en cas d'incidents/dégradations coûteuses.

8) Comportement du client et protocole

Codes : '429 Too Many Requests' (taux), '403' (quota/plan dépassé), '503' (dégradation protectrice).

• « Retry-After : » - quand essayer à nouveau.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff : exponentielle + jitter (full jitter, equal jitter).
• Idempotence : titre 'Idempotency-Key' et répétabilité des opérations sécurisées.
• Temporisation et annulation : Interrompre correctement les requêtes suspendues afin de ne pas « capturer » les limites.

9) Observabilité et tests

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Métriques : bande passante, proportion de pannes de 429/403/503, p95/p99 latence limite, cache de clé hit ratio, répartition par plan.
Logs d'audit : causes des blocs, haut clés « bruyantes ».
Tests : profils de charge « scie/burst/plateau », chaos - panne Redis/shard, dissynchronisation de l'horloge.

10) Intégration avec facturation

Les compteurs d'utilisation sont collectés à la frontière, agrégés par des trampolines (toutes les N min) avec idempotence.
Résumé par plan : dépassement de crédits → surcharge ou augmentation temporaire du plan.
Différences : rapprochement de l'utilisation vs invoice ; alerte sur le delta.

11) Fairness à l'intérieur (files d'attente, workers)

Weighted Fair Queuing/DRR : répartition des créneaux horaires entre locataires selon le poids du plan.
Per-tenant worker pools : isolation rigide VIP/bruyants.
Contrôle de l'admission : refus avant l'exécution si les quotas sont épuisés ; les files d'attente ne sont pas gonflées.
Caps sur la concurrence : limiter les jobs lourds simultanés.

12) Profils types des plans (exemple)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) Référence architecturale (schéma verbal)

1. Passerelle Edge/API : TLS → extraire le contexte (tenant/plan) → vérifier les limites/quotas → placer les en-têtes RateLimit- → log/train.
2. Moteur de politique : règles de priorité (VIP), seuils adaptatifs.
3. Limiter Store : Redis/KeyDB (atomic ops, LUA), Chardonnage de clés, réplication.
4. Services : limite secondaire et caps pour les opérations lourdes ; l'idempotence ; files d'attente avec WFQ/DRR.
5. Utilisation/Billing : collecte, agrégation, facturation, alertes selon les seuils.
6. Observability : métriques/logs/trajets étiquetés, dashboards per-tenant.

14) Chèque-liste avant la vente

• Les scopes des limites (tenant/user/token/endpoint/IP) et leur hiérarchie ont été définis.
• L'algorithme (Token Bucket/GCRA) et les paramètres 'rate/burst'ont été sélectionnés.
• Mise en œuvre de caps de concurrence et de contrôle d'admission pour les opérations lourdes.
• Les titres « RateLimit- » et « Retry-After » sont inclus ; les clients prennent en charge backoff + jitter.
• Limite distribuée et résistante aux pannes (chardes, réplication, dégradation).
• La collecte d'utilisation est idempotente ; lien avec la facturation, alertes de dépassement.
• Observabilité : métriques/trajets/logs étiquetés, clés « bruyantes » supérieures, alerter's.
• Tests : burst, « scie », panne de store, clock skew, démarrage froid.
• Documentation pour les clients : limites par plan, exemples de 429/Retry-After, meilleures pratiques rétroactives.
• Politique d'exclusion : comment augmenter temporairement les limites et quand.

15) Erreurs typiques

La limite globale sans per-tenant/per-endpoint - « noisy neighbor » brise tous les SLO.
Absence de 'burst' : UX souffre de courts éclats.
Utilisez uniquement une fenêtre fixe → « double impact à la limite de la fenêtre ».
Il n'y a pas d'idempotence et de retraits avec un jitter → une tempête de répétitions.
Limites uniquement à la frontière, pas de caps dans les services/files d'attente → « embouteillages » internes.
La non-lecture des limites dans les réponses (non « Retry-After », « RateLimit- ») → les clients ne s'adaptent pas.
Le stockage de l'état du limiteur dans la base de données OLTP → une latence élevée et des verrous « chauds ».

16) Sélection rapide de la stratégie

API publiques avec des pics : Token Bucket + grand 'burst', RateLimit-heads, CDN/edge cache.
Jobs lourds internes : caps de concurrence + WFQ/DRR, contrôle d'admission.
Intégrations avec des tiers : limites de sortie séparées, tampons/retraits.
Multi-tenant SaaS : hiérarchie des limites (global→tenant→user→endpoint), priorité VIP, quotas par mois.

Conclusion

Les bons taux limites et quotas sont un contrat systémique entre la plate-forme et le client : une juste part des ressources, une résistance aux surtensions, un SLO prévisible et une facturation transparente. Combinez des algorithmes (Token/GCRA + caps de concurrence), mettez en place une hiérarchie de scopes, donnez des titres et des métriques compréhensibles, et vérifiez régulièrement les schémas sous les profils de trafic réels - de sorte que la plate-forme restera durable même avec une augmentation agressive de la charge.