Limites de taux et contrôle de charge

TL; DR

Une boucle robuste est une combinaison de limites et de quotas à plusieurs niveaux (edge→BFF→servis), une répartition équitable des ressources (per-tenant/key/routh), un câble adaptatif SLO et un backpercher au lieu de temps silencieux. Utilisez token/leaky bucket pour la « vitesse », une fenêtre glissante pour les quotas comptables, des limites concurrentielles pour les opérations lourdes, le throttling dynamique en cas de dégradation et un circuit-breaker pour les apstrymes fragiles. C'est sous surveillance et avec des pleybuks.

1) Pourquoi les limites dans iGaming/fintech

SLO et résilience : protection contre les avalanches de rétrograves, les pics de tournois/events, les surtensions de paiement.
Justice : un tenant ou un partenaire ne « aspire » pas tout le budget.
Antiabus/bots : Dorilimitage login/enregistrement, spam, scraping de catalogues.
Coût : dissuasion des appels coûteux (KYC, rapports, agrégations).
Conformité/utilisation de bonne foi : quotas formels « fair use » dans les contrats.

2) Taxonomie des limites

3) Algorithmes et où appliquer

3. 1 Token Bucket (par défaut)

Options : 'rate' (tokens/s), 'burst' (stock max).
Excellent pour API read, paiement/statuts, BFF.
Si le réservoir est vide, → 429 + « Retry-After ».

3. 2 Leaky Bucket (moyenne)

La « démolition » RPS garantie est utile pour les webhooks afin de ne pas marquer les workers.

3. 3 Fixed Window vs Sliding Window

Fixe - simple, mais « limites » ; Sliding - comptabilité honnête dans la fenêtre (min/heure/jour).
Appliquez Sliding aux quotas contractuels.

3. 4 Concurrent Limits

Limite des tâches actives simultanément. Idéal pour les exportations/reports, les paquets KYC, les retraits.
En cas de pénurie - 429/503 + file d'attente/polling.

3. 5 Cost/Complexity Limiter

GraphQL/recherche : nous considérons le « coût » par profondeur/cardinalité/extensions.
Coupure/dégradation des requêtes « chères », réponse avec conseil.

4) Clés de limitation (dimensioning)

per-tenant (multiarend, justice),

per-api_key/client_id (partenaires),

per-route (mutations critiques plus sévères),

per-user/device/IP/ASN/geo (antibot/antiscrape),

per-BIN/pays (méthodes de paiement, protection des émetteurs et des fournisseurs),

per-method (GET soft, POST/PUT plus strict).

Composition : clé principale + « multiplicateur de risque » (nouveau compte, TOR/proxy, risque de charge élevé).

5) SLO-Adaptive Trottling

• Déclencheurs : 'p95 latency↑', '5xx↑', 'queue len↑', 'CPU/IO saturation'.
• Actions : abaisser le taux/burst, activer outlier-ejection, réduire les routes « chères », dégrade temporaire (pas de champs/agrégations lourds).
• Retour : pas à pas (25→50→100 %) lors de la normalisation des signaux N intervalles consécutifs.

6) Intégration dans l'architecture

API Gateway (edge) : rate/quotas primaires, géo/ASN, HMAC/JWT-validation, 429/« Retry-After ».
BFF/Service Mesh : limites fines per-route/per-tenant, limites concurrentes, circuits-breakers aux aptrimes.
Dans le service : sémaphores pour les opérations lourdes, backpresher sur les files d'attente, « pools de travail » avec la taille bound.
Webhooks : ingress-endpoint séparé avec leaky bucket et tampon rétracteur.

7) Configurations (fragments)

yaml plugins:
- name: rate-limiting config:
policy: local minute: 600    # 10 rps limit_by: consumer fault_tolerant: true
- name: response-ratelimiting config:
limits:
heavy: { minute: 60 }

yaml circuit_breakers:
thresholds: { max_connections: 1000, max_requests: 800 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s http_filters:
- name: envoy. filters. http. local_ratelimit typed_config:
token_bucket: { max_tokens: 100, tokens_per_fill: 100, fill_interval: 1s }
filter_enabled: { default_value: 100% }
filter_enforced: { default_value: 100% }

pseudo sema = Semaphore(MAX_ACTIVE_EXPORTS_PER_TENANT)
if! sema. tryAcquire(timeout=100ms) then return 429 with retry_after=rand(1..5)s process()
sema. release()

pseudo cost = sum(weight(field) cardinality(arg))
if cost > tenant. budget then reject(429,"query too expensive")

8) Politiques pour les différents canaux

REST

GET - plus doux, POST/PATCH/DELETE - plus strict ; les statuts/contrôles « idempotent » peuvent être rétractés.
Pour les paiements : les limites sur ' auth/capture/refund ' per-user/tenant/BIN/страна.

GraphQL

Depth/complexity caps, persisted/whitelisted queries, limites pour les « alias ».

WebSocket/SSE

Limite de fréquence 'subscribe/unsubscribe', cap sur le nombre de points de repère, contrôle de la taille des événements et send-queue → lorsque « policy _ disconnect » est dépassé.

Webhooks

Leaky bucket à la réception, par sender quota, dead-letter queue, déterministes 2xx/429.

9) Rétroaction aux clients

• `Retry-After: `
• `X-RateLimit-Limit/Remaining/Reset`
• Pour les quotas, 403 avec le code « quota _ exceeded » et la référence de mise à niveau du plan.
• Documentation : limites dans OpenAPI/SDL + page « Fair Use ».

10) Monitoring et dashboards

• Les succès des limites sont : 'rate. limit. hit 'par clés/routes/tenants.
• 429/503 доля, latency p50/p95/p99, error rate, queue length, open circuits.
• Fair-share : top tenants de la consommation, « detector bully ».
• Webhooks : réception/retrai, drop-rate, lag moyen.

• 429 pas plus de 1 à 3 % du RPS total (pas de bots).
• p95 supplément de limite ≤ 5-10 ms par edge.
• Temps de récupération après dégradation ≤ 10 min.

sql
SELECT ts::date d, tenant, route,
SUM(hits) AS limit_hits,
SUM(total) AS total_calls,
SUM(hits)::decimal/NULLIF(SUM(total),0) AS hit_rate
FROM ratelimit_stats
GROUP BY 1,2,3
ORDER BY d DESC, hit_rate DESC;

11) Pleybooks d'incidents

Tempête de rétrograves (chute de l'apstream) : inclure le throttling global, soulever le backoff, ouvrir le circuit-breaker, renvoyer les « erreurs rapides » au lieu des time outs.
Attaque bot/scraping : cap dur par IP/ASN/geo, activer le défi WAF/JS, limiter les répertoires/recherches.
Le pic du tournoi/event : augmenter préventivement les limites de lecture, réduire les « champs chers », inclure le cache/dénormalisation.
Les webhooks de PSP ont été révélés : Bukket de leaky temporaire, hiérarchisation des types critiques, extension du dead-letter et des retraits.

12) Test et UAT

Charge : RPS par escalier, bourrelets × 10 de normal.
Justice : l'émulation de 1 tenant « avide » n'est pas supérieure à X % du budget mondial.
Dégradation : L'adaptation SLO réduit les limites et maintient la p95 dans le couloir.
Cas limites : changement de fenêtre (min→chas), tremblements d'horloge (clock skew), mise à l'échelle des clés Redis/Charding.
Contrat : les titres 429 et Retry-After sont présents, le SDK est correctement back-off.

13) Stockage pour les limites

In-memory pour les limites locales (petits clusters).
Redis/Memcached pour les scripts distribués (Lua-scripts pour l'atomicité).
Chardonnez les clés par hachage ; TTL sous les fenêtres ; métrique backap pour la perte de cache.
Idempotency : le limiteur ne doit pas casser les appels à répétition idempotent (compte tenu de la clé de requête).

14) Gestion des politiques (Gouvernance)

Catalogue des limites : qui est le propriétaire, quelles clés/seuil/ration.
Feature-flags pour commutateurs rapides (crisis mode).
La révision des politiques et le processus RFC pour modifier les quotas contractuels.
A/B expériences de sélection des seuils optimaux.

15) Anti-modèles

Une limite globale par API.
Seules les fenêtres fixes → les sauts de bord.
Limite sans rétroaction (non « Retry-After »/headers).
Temporisation silencieuse au lieu de rapide 429/503.
Pas de per-tenant fair-share - un client étrangle les autres.
Il n'y a pas de protection GraphQL/recherche par complexité.
Zéros dans le concours-garde → « aspirateur » OBD/PSP.

16) Mini maquette de choix

Par défaut : token bucket (rate + burst) per-tenant + route.
Quotas d'argent/rapports : sliding window 24 heures/mois.
Opérations lourdes : concours-limites + file d'attente.
GraphQL/поиск: complexity-budgets + persisted queries.
WS/webhooks : leaky bucket + backpressure.
Кризис: dynamic throttling + circuit-breaker + degrade.

Résumé

Le contrôle de charge est une discipline à plusieurs niveaux : algorithmes corrects (bucket/fenêtres/compétitivité), clés de limitation justes, adaptation SLO et rétroaction transparente. En plaçant des limites dans gateway/mesh/services, en armant GraphQL/WS/webhooks avec des polices de profil et en connectant l'observation avec des pleybooks, vous transformez les événements de pointe et les pannes des autres en situations gérables - sans débris, sans paiement et sans conversion.