Technologie et infrastructure → Latency et optimisation de la réponse API

Latitude et optimisation de la réponse API

1) Qu'est-ce que « latency » et pourquoi est-ce important

Latency est le retard total de la requête : réseau (DNS + TCP + TLS + RTT), balancier/passerelle, application, bases de données/caches/files d'attente, intégrations externes. Pour les entreprises, les P95/P99 sont critiques, pas la moyenne : c'est la « queue » qui ruine UX, CR et SLO.

• 'SLI _ latency _ P95 = P95 (temps _ réponse) 'en 5/30 minutes
• 'SLI _ latency _ P99 = P99 (temps _ réponse) '
• 'SLI _ queue _ time = P95 (temps _ dans _ file _ worker) '
• 'SLI _ ext _ call _ P95 = P95 (latence _ externes _ fournisseurs) '

2) Carte des sources de retard (et où creuser)

1. Réseau et protocoles : DNS, TCP handshakes, TLS, head-of-line (HTTP/1. 1), perte de paquets, BBR/ECN.
2. Passerelle/balancier : lent health-check, temps non valides, pods chauds.
3. Application : verrous, GC/stop-the-world, I/O synchrone, contenu.
4. Stockages : Requêtes OBD lentes, absence d'index, pages froides.
5. Services externes : PSP/KYC, API tierces (SLA étroits).
6. Files d'attente et jobs d'arrière-plan : workers surchargés, pas de backpressure.
7. Cache/edge : manque de cache, TTL faible, invalidité non validée.

3) Réseau et protocoles

3. 1 DNS/TCP/TLS

DNS prefetch/preconnect sur le front, IP longue durée à PSP.
Keep-Alive/connection pooling dans les clients ; sur le serveur - agrégez les connexions.
TLS : resumption/Session Tickets, un paquet de cryptage moderne ; éviter les 0-RTT pour les opérations idempotentes dangereuses.
TCP : désactiver Nagle ('TCP _ NODELAY') pour les chat/petits paquets ; tune 'initial window', activez le BBR le cas échéant.

3. 2 HTTP/2 и HTTP/3

HTTP/2 : le multiplexage réduit les verrous HOL des HTTP/1. 1; suivre les priorités des flux.
HTTP/3/QUIC : ci-dessous l'impact des pertes/RTT ; utile sur un réseau mobile/international.
Compression de tête : HPACK/QPACK, mais garder la taille raisonnable des titres.

3. 3 Équilibrage/itinérance

Locality-aware (zonalité), EWMA/least-request contre les instances « chaudes ».
La soudure des sessions - seulement s'il y a un état ; sinon, stateless + cache/session partagé.

4) Formats, charge utile, compression

Compressez : Brotli (texte), Gzip comme fallback ; formats binaires : Protobuf/Avro pour gRPC/API internes.
Réduire payload : champs sélectifs ('fields =...'), pagination, GET conditionnel (ETag/If-None-Match), réponses delta.
GraphQL : queries persistantes, interdiction des fragments « gras », limites de profondeur et de complexité.
Évitez N + 1 : joyaux/précomposition, endpoints de batch pour les agrégats.

5) Taymouts, Retrai, Idempotence

Temporisation par chaîne : Client <passerelle <appa <stockage/appel externe.
Retrai avec backoff + jitter, uniquement pour les erreurs temporaires ; exposez les budgets sur les retraits.
Idempotence : clé/jeton de requête + sauvegarde du résultat ; les retraits ne doivent pas faire double emploi avec les opérations (notamment financières).
Circuit Breaker : ouvrir en cas de dégradation ; hedged/backup requests pour les « queues » (envoyer un double via P95).

6) Files d'attente, asynchrone et backpressure

Ne bloquez pas le chemin synchrone : opérations lourdes (scans KYC, rapports) - dans l'arrière-plan.
Backpressure : limitez la consommation de la file d'attente, fixez le parallélisme.
Batching/coalescing : combinez les petites opérations (par exemple, mise à jour des bilans avec agrégation).
Outbox/Inbox : livraison garantie des événements en cas de refus.

7) Annexe : Rantaymes et pools

Pools de connexion aux bases de données/caches/NTTR ; limitez-les pour ne pas « étrangler » le backend.
JVM : profilage GC (G1/ZGC), éviter les grandes allocations ; .NET - ThreadPool/async ; Node. js - ne bloquez pas l'event loop, sortez le CPU lourd.
Python : pilotes asynchrones (asyncpg/httpx), uvloop ; Tâches CPU via worker-pool.
Warm-up : Réchauffez les JIT/caches, les « warm pools » des instances aux pics.

8) Bases de données et caches

Indices et plans : régulier 'EXPLAIN', auto-vide/analyse, limite de balayage.
Connection pooling (PgBouncer/Multiplexing), transactions courtes.
Stratégies de cache : read-through, write-through/write-behind ; TTL + handicap par évènements.
Charding/répliques : lecture à partir de slaves, « clés chaudes » sont des caches locaux (near-cache).

9) Cache et edge

CDN/edge pour statiques/répertoires, cache de réponses API (si sécurisé) par Cache-Control, ETag.
Stale-while-revalidate et stale-if-error pour la résilience UX.
Répartition géographique : la RR/région la plus proche réduit la RTT.

10) Modèles architecturaux contre les résidus P99

Demandes d'autorisation : dupliquez une demande lente pour une autre instance après le seuil.
Demande de collapsing : une demande « maître » à la base de données, les autres attendent le résultat (évite les tempêtes).
Priorité : Opérations VIP/critiques - pool/priorité dédié.
Graceful degradation : coupez les champs/widgets secondaires en cas de surcharge.

11) Configi (environ)

11. 1 NGINX (temporisation/compression)

nginx proxy_connect_timeout  1s;
proxy_send_timeout   2s;
proxy_read_timeout   2s;
send_timeout      2s;

gzip on;
gzip_types application/json text/plain text/css application/javascript;

11. 2 Envoy (hedge + retry budget)

yaml
RetryPolicy:
retry_on: 5xx,reset,connect-failure num_retries: 2 per_try_timeout: 300ms retry_back_off: { base_interval: 50ms, max_interval: 200ms }
retry_priority:
name: envoy. retry_priorities. previous_priorities
HedgePolicy:
hedge_on_per_try_timeout: true initial_requests: 1 additional_request_chance: 0. 2

11. 3 gRPC (client)

json
{
"methodConfig": [{
"name": [{"service": "payments. Service"}],
"timeout": "0. 8s",
"retryPolicy": {
"maxAttempts": 3,
"initialBackoff": "0. 05s",
"maxBackoff": "0. 2s",
"backoffMultiplier": 2. 0,
"retryableStatusCodes": ["UNAVAILABLE","DEADLINE_EXCEEDED"]
}
}]
}

12) Observability : Mesurez correctement

Métriques RED/USE + trajets OTel : 'trace _ id' via l'API externe gateway-service-OBD.
Étiquettes individuelles : 'api _ version', 'region', 'partner', 'endpoint'.
Dashboards : P50/P95/P99, queue time, error mix, retry rate, cache hit.
Synthétiques des pays cibles/ASN (TR/BR/EU) et par voies critiques (reg→depozit, payout).

• API core : 'P95 ≤ 250ms', 'P99 ≤ 500ms' (30 jours)
• Traitement de webhook PSP : 'P99 ≤ 60s' avec retraits
• Catalogue Freshness : 'P95 lag ≤ 30'

13) FinOps и latency

Les millisecondes coûtent de l'argent : évaluez les gains de $/ms en CR/ARPPU.
Right-sizing : plus rapide ≠ plus cher toujours ; un cache/formats compétents sont bon marché et accélèrent.
Egress/edge : Le CDN réduit la RTT et le coût du trafic sortant de la région.

14) Chèque d'optimisation (étape par étape)

1. Mettez un SLO et mesurez les résidus (P95/P99) par endpoints/régions/partenaires.
2. Activez le HTTP/2/3, la résolution TLS, les connexions à longue durée de vie.
3. Serrer et perdre du poids réponses : Brotli/Gzip, champs sur demande, pagination, ETag.
4. Ajustez les temporisations/retraits/breakers ; ajouter l'idempotence.
5. Cache/edge : hit-rate et TTL corrects ; stale-modes.
6. OBD : indices, plans, pools, répliques ; éliminer N + 1.
7. Asynchronisez lourd : files d'attente, batch, backpressure.
8. Hedge/collapse/priority pour les voies critiques.
9. Warm-up et skating prédictif aux pics (tournois/matchs).
10. Synthétiques et alertes sur P99 et queue time ; perf-revu régulier.

15) Anti-modèles

Une seule temporisation mondiale « sur tout » et des retraits incontrôlables (DDOS).
Il n'est pas nécessaire de → des notes chaudes.
Grand JSON sans compression et sans filtres de champ.
Appels synchrones vers des API externes lentes dans le « chemin chaud ».
Absence d'indices/limites dans les bases de données ; N + 1 dans l'ORM.
Pas de cache/edge et ETag ; réponses complètes constantes.
Mélange d'erreurs commerciales et techniques dans un panier « rétractable ».

16) Contexte iGaming/fintech : notes pratiques

Reg→depozit (CR) : priorité des itinéraires, pool séparé, 'P99 ≤ 500ms' ; dégradation - désactiver les « bijoux » UI.
Intégration PSP : limites concarrensy, retraits par code temporel, connexions warm, egress-IP régionale.
Opérations VIP : pool garanti/priorité, contournement des files d'attente partagées.
Tournois/events : skale prédictif, échauffement des caches, préfetch.
Reporting : async et SLA sur freshness, ne bloque pas le chemin d'accès.

Résultat

L'optimisation de la latitude est une discipline d'équilibre : réseau (HTTP/2/3, TLS), protocoles et cache, temporisation/rétraction avec idempotence, OBD/cache, modèles asynchrones et observabilité des P95/P99. En vous concentrant sur les queues et en éliminant les « gorges étroites », vous stabiliserez la réponse, améliorerez la conversion et réduirez le coût de la milliseconde - là où cela affecte vraiment l'entreprise.