Optimisation de la réponse backend : files d'attente, async, backpressure

1) Pourquoi : objectifs et SLO

L'objectif est une réponse rapide stable même sous les éclats. Les entreprises expriment ce SLO :

API (CRUD/répertoires) : p95 ≤ 250-400 ms, taux d'erreur <1 %.
Paiement/settlment (asynchrone) : SLA interne pour la confirmation ≤ 2-5 min, et le client - instantané 202/Accepted + statut poller/webhook.
WS/real-time: RTT p95 ≤ 120 мс, disconnect ≤ 0. 5%.

Clé : séparer les étapes « lentes » (fournisseurs, bases de données, API externes) de la réponse de l'utilisateur via les files d'attente et une limitation de charge compétente.

2) Image de base : où la latence est prise

Goulets d'étranglement : OBD (pools/index), fournisseurs externes (PSP/jeux), bloquant I/O, GC/monde stop, sérialisation JSON, agrégations « lourdes ».

Symptômes : croissance de la p99, file de connexions à l'OBD, surtensions de rétrogrades, time out par chaîne (retry storm).

Antidote : convoyeurs asynchrones + backpressure + temporisation/rétraction + idempotence.

3) Modèles asynchrones : SEDA et CQRS

SEDA (Staged event-driven architecture) : décomposez le traitement au stade (ingress → validation → enregistrement → intégration → notification). Chacun a son tour et ses limites de parallélisme.

CQRS : séparez les lectures et les écritures. L'écriture est dans le journal/base, la lecture dans les projections/caches.

Outbox : l'événement est publié atomiquement avec l'enregistrement (on évite les messages « perdus »).

Saga : longs processus d'affaires avec des transactions compensatoires au lieu de transactions globales.

4) Files d'attente et strimes : sélection et tuning

RabbitMQ/NATS JetStream - commandes de tâches (work queues), Kafka - événements/strimes avec un relais.

Paramètres qui affectent la réponse :

Prefetch/max in-flight : limitez le nombre de messages traités simultanément sur le worker (par exemple 16-64) afin de ne pas « marquer » la base de données/API externe.
Acker/répétitions : 'ack' après l'enregistrement idempotent ; répétitions avec retard exponentiel et jitter.
DLQ/parking lot : Il n'y a pas de retraits sans pointes - après N tentatives, il part pour Dead Letter Queue.
Lot (Kafka) : Clé par entité (userId/txnId) pour ordonner ; parallélisme par le nombre de lots.

5) Pression inverse (backpressure) - comment ne pas se noyer

L'idée est de ne prendre que la quantité que vous pouvez traiter dans la latence de SLO.

Techniques :

Contrôle d'admission : limitez la concurrence (semaphore/worker-pool) à chaque dépendance externe : DB, PSP, fournisseur de jeux.
Traffic shaping : token-bucket/leaky-bucket à l'entrée du service et sur les itinéraires critiques.
Files d'attente avec bordure supérieure : lors du remplissage - couper la queue (429/503 + Retry-After) ou le traduire en asap-batch.
Concurrence adaptative (AIMD) : développez le parallélisme lorsque vous réussissez, réduisez lorsque vous êtes en retard.
Circuit Breaker : 'closed → open → half-open' sur les erreurs/temporisations de l'API externe ; lors de l'ouverture, la dégradation (cache/sous).

Pseudo-code (Go-like) :

go bou : = make (chan structure {}, 64 )//limite de concurrence à l'OBD/PSP

func handle(req) {
select {
case sem <- struct{}{}:
defer func(){ <-sem }()
ctx, cancel:= context. WithTimeout(req. ctx, 300time. Millisecond)
defer cancel()
res, err:= db. Do(ctx, req)
if err == context. DeadlineExceeded { metrics. Timeouts. Inc(); return TooSlow() }
return Ok(res)
default:
metrics. Backpressure. Inc()
return TooBusy(429, "Retry-After: 0. 2")
}
}

6) Time out, retrai et jitter : « trois baleines de survie »

Les temporisations sont plus courtes que SLO : Si SLO 400 ms, temporisation à l'OBD/fournisseur 250-300 ms ; Délai total de la demande <400-600 ms.

Retrai limité et intelligent : 1-2 essais max, uniquement pour des opérations sécurisées (idempotent), avec exposant et gitter.

Coalessing : agrégez les répétitions pour une seule clé.

Pseudo-code (exposant + gitter) :

python for attempt in range(0, 2):
try:
return call(dep, timeout=0. 3)
except Timeout:
backoff = (0. 05 (2attempt)) + random. uniform(0, 0. 05)
sleep(backoff)
raise UpstreamUnavailable

7) Idempotence et déduplication

Idempotency-Key sur HTTP (dépôts, paiements), 'operation _ id'dans la base de données (index unique).

Inbox/Outbox : les webhooks entrants sont toujours via une table inbox immuable de dedupe à 'event _ id' ; les sortants proviennent de l'outbox par transaction.

Exactly-once « par sens » : nous autorisons la livraison/exécution répétée, mais l'effet est unique.

8) API rapide pour les opérations lentes

Réponse synchrone : 201/202 + URL de statut ('/status/{ id} '), ETA et conseils rétractés.

Webhooks/Server-Sent Event/WS - State push lorsque vous êtes prêt.

Discipline client : 'Retry-After', idempotence, limite de sondage.

Exemple de réponse :

json
HTTP/1. 1 202 Accepted
Location: /v1/withdrawals/req_9f2/status
Retry-After: 2
{
"request_id": "req_9f2",  "state": "processing",  "next_check_sec": 2
}

9) Minimiser le travail dans le chemin chaud

Mettez les choses lourdes en arrière-plan : transformations, agrégations, notifications, écriture dans DWH.

Cache et projections : souvent lu - cache-aside avec un court TTL et un handicap d'événement.

Modèles de batch : regroupez les appels externes (par exemple, demander les limites du fournisseur une fois par N ms).

Sérialisation : Codecs rapides (protobuf/msgpack) pour les liens interservices ; JSON est seulement sur edge.

10) OBD sous contrôle

Pools de connexions : les limites supérieures (basées sur les noyaux/IO), les files d'attente vers le pool sont incluses.

Indices et plan : p95 explain + autotests de régression des plans.

Délais de requête : courts, 'statement _ timeout' (Postgres).

Hot rows/locks : chardonnages par clé, verrous optimistes (version bilan), saga au lieu d'une transaction « monolithique ».

11) WebSocket/real-time

Limiteur à la newsletter : batched broadcast, max msgs/sec per connection.

Backpressure interne : file d'attente des messages sortants avec le capuchon ; en cas de débordement - drop low-priority.

Sticky-routing et PDB lors des sorties - pour ne pas fructifier la tempête reconnect.

12) Observabilité pour ne pas deviner

Métriques (RED/USE + backpressure) :

« request _ rate », « error _ ratio », « latency _ p95/p99 » le long des itinéraires.
`queue_depth`, `lag_seconds`, `consumer_inflight`, `retries_total`, `dlq_rate`.
`backpressure_drops`, `admission_rejects`, `circuit_open`.
Для БД: `connections_in_use/max`, `locks`, `slow_queries`.
Traces : spans 'queue → worker → db/psp' avec les balises 'opération _ id', 'partition', 'retry'.
Logs : structurels, avec 'trace _ id', sans PII ; événements individuels « circuit ouvert/fermé ».

13) Essai sous charge

Open-model (arrivals/sec) pour les surtensions ; Closed-model (VUs) pour les sessions.

Profils : brèves burst 60-120 s et soak 1-4 h.

Injections d'échec : ralentissez l'API externe de + 200-500 ms, regardez p99/retrai/files d'attente.

Critères de zone verte : sans croissance 'queue _ lag', p95 stable, 'dlq_rate≈0'.

14) Sécurité et fiabilité

Files d'attente TLS/mTLS, signature des messages, contrôle du schéma (Avro/Protobuf + Schema Registry).

Idempotent producteur (Kafka), exactly-once tx lorsque justifié.

Mode chaos : périodiquement « réduire » la dépendance et regarder la dégradation (circuit, fallback).

15) Exemples de « pièces » de configurations

Nginx/Envoy shaping d'entrée :

nginx limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
location /api/ {
limit_req zone=api burst=40 nodelay;
proxy_read_timeout 0. 6s ; # raccourci SLO proxy_connect_timeout 0. 2s;
}
}

RabbitMQ (prefetch):


basic. qos (prefetch_count = 32) # bilan CPU/IO

Kafka consumer (fragment Java) :

java props. put(ConsumerConfig. MAX_POLL_RECORDS_CONFIG, 200);
props. put(ConsumerConfig. FETCH_MAX_BYTES_CONFIG, 5_000_000);
props. put(ConsumerConfig. MAX_POLL_INTERVAL_MS_CONFIG, 60_000);

16) Chèque de mise en œuvre (prod-ready)

Les chemins critiques sont divisés en réponse synchrone et traitement asynchrone (SEDA).
Contrôle d'admission et limites de concurrence sur les dépendances externes.
Les délais sont plus courts que SLO ; Retrai ≤ 2, avec exposant et jitter ; le coalessing.
Circuit breaker + dégradation (cache/back), politique half-open.
Files d'attente/strim : prefetch/in-flight, DLQ, lots par clés.
Idempotence (operation_id/Idempotency-Key), Outbox/Inbox, déduplication.
Cache : cache-aside, court TTL + handicap d'événement.
Bases de données : limites des pools, statement_timeout, index, stratégie anti-lock.
WS : limites de message, batch, sticky-routing, PDB.
Observabilité : métriques backpressure/queues/retries, tracés de fin à fin, dashboards.
Tests de charge et de défaillance (open + closed, burst + soak), critères de zone verte.

Résumé

Le backend rapide n'est pas « faire un cache de plus », mais un flux contrôlé : l'entrée est limitée, lourde - dans l'arrière-plan, chaque étape avec des files et des limites, les retraits sont rares et intelligents, et les chaînes sont protégées par le circuit breaker et l'idempotence. Ajoutez la discipline du timing, de l'observabilité et des tests de stress réguliers - et votre p95/p99 restera vert même sous les tempêtes et les caprices des fournisseurs externes.