API passerelle et routage

1) Rôle de la passerelle API dans l'architecture

• Route les requêtes (par chemin/headers/geo/poids/version).
• Protège le périmètre (TLS/mTLS, WAF, DDoS, rate limits, authN/Z).
• Contrôle le trafic (canary/AB, shadow/mirror, circuit breaker, retraits, timeouts).
• Normalise les protocoles (REST/gRPC/WebSocket), les en-têtes, les codes.
• Observe (logs, métriques, traces, corélation).
• Transforme et valide (JSON/XML, normalisation, schema-validation).

Pour iGaming, c'est aussi la géo-conformité (verrouillage par pays/âge), le smart rowting payant et les politiques de jeu responsable sur le bord.

2) Options de routage

Path-based: `/api/v1/payments/ → payments-svc`.
Host-based: `eu. api. example. com → eu-edge`, `psp. example. com → psp-proxy`.
Header-based : 'X-Client : partner-A' → partner backend ; 'Accept : application/grpc'.
Géo-routing : par IP/ASN/pays (RGPD/interdictions locales, latitude).
Weighted/Canary : « 90 % » sur l'ancienne, « 10 % » sur la nouvelle version ; un retour rapide.
Claim-routing: по `JWT. claims. tier/role/region '(par exemple, haut-roller → limites premium).
Failover : actif-actif/actif-passif entre les centres de données/cloud et PSP.

3) Sécurité du périmètre

TLS everywhere: TLS 1. 2 + sur l'extérieur, mTLS à l'intérieur (shlyuz↔servisy).
OAuth2/JWT : vérification de la signature, audit « bou/nbf/aud/scope », rotation JWKS ; kesh de validation avec TTL.
HMAC : signature des corps pour les webhooks/paiements.
Clés API : pour les clients système ; nous associons les quotas/rôles.
WAF : règles de base (injection, protocol anomalies), taille du corps, deny list des pays.
Protection DDoS : connection limiting, cookies SYN, rate-limit sur IP/clé/endpoint.
Zero-Trust : Politiques de mandat (SPIFFE/SPIRE, identités des services), principe des droits les plus faibles.
Vie privée : modification des PII dans les logs, masquage PAN/IBAN, politique de stockage.

4) Limites, quotas et protection contre les bourgeons

Модели: token bucket, leaky bucket, fixed/sliding window.
Bordures : per-IP, per-key, per-user, per-route.

• Burst + sustained (par exemple, '50 rps burst', '10 rps sustain').
• Retry-Budget et Slow-Loris Protection.
• Quota par jour/mois pour les partenaires.

5) Transformation et validation

Normalize des titres (trace-id, locale, client-id).
Request/Response-mapping (champs/codes, masquage des attributs internes).
La validation de Schema (OpenAPI/JSON Schema) est une défaillance précoce de 4xx.
Compression/' Accept-Encoding ', caching (voir ci-dessous).

6) Cache et performance

Edge-cache pour les manuels, les métadonnées publiques, les configues (TTL, « ETag »/« If-None-Match »).
Micro-cache 1-5 s par GET chaud (réduit la charge de pointe).
Negative-cache court (sur 404/empty) - prudent.
Hedging-requests et demandes concurrentielles de répliques à p95> seuil.

7) Timouts, Retrai, Résilience

Temporisation : connect/read/write séparément ; des repères p95 raisonnables.
Retrai : méthodes idempotent (GET/PUT) avec backoff + jitter ; retry-budget.
Idempotence POST : 'Idempotency-Key' + déduplication côté service/passerelle.
Circuit-Breaker : par erreur/latitude ; échantillon half-ouvert.
Bulkhead/Pool-isolation par aptrimes.

8) Versioning et compatibilité

• URI : '/v1/... '(juste, mais « bruyant » les itinéraires).
• Header/Content-Negotiation: `Accept: application/vnd. app. v2+json`.
• Fonction Flags/capability du serveur - pour la compatibilité des modifications mineures.

Stratégie : BouVer, fenêtre de support (par exemple, 'v1' = 12-18 mois), graphique de privations, réponses compatibles lors des extensions (l'ajout de champs ne brise pas).

9) Observation et contrôle de la qualité

Corrélation : 'traceparent '/' x-request-id' est obligatoire ; Nous allons vers le bas.
OpenTelemetry : métriques d'événements de RPS/p50/p95/p99/5xx/4xx, de saturation, de retri/circuit.
Logs : JSON structurel ; nous masquons le PII ; niveaux par code.
Samplage des tracés : base 5-10 % + cible pour les erreurs/lent.
SLO/alertes : par itinéraire/clients (aptyme, latency, erreur).

10) Gestion du trafic de sortie

Bleu-Vert : commutation DNS/LB.
Canary : part de poids/segments (région, partenaire, rôle).
Shadow/Mirror : copie du trafic vers la nouvelle version sans réponse au client.
Kill-switch : drapeau pour désactiver rapidement le problème d'apstream/fichi.

11) Routage de paiement intelligent (iGaming)

Règles de sélection de PSP : géo, devise, montant, risque, disponibilité, commission.
Failover PSP : passage automatique à '5xx/timeout'.
Same-method rule : retours/conclusions via la méthode originale - vérification au bord.
Idempotence de paiement : clé sur 'userId + amount + currency + purpose'.
Transparence ETA : la passerelle ajoute les statuts et les causes des pannes (pas les codes PSP).

12) Politiques croisées et conformité

Filtres géo : Listes des pays blancs/noirs, limites d'âge, IP-Rainji.
Données des résidents : acheminement vers des clusters régionaux (RGPD/lois locales).
Logs et TTL : stockage par région, anonymisation automatique.

13) Exemples de configurations

13. 1 NGINX (routage + limite + headers)

nginx http {
map $http_x_request_id $req_id { default $request_id; }
limit_req_zone $binary_remote_addr zone=per_ip:10m rate=20r/s;

server {
listen 443 ssl http2;
server_name api. example. com;

Security add_header Strict-Transport-Security "max-age = 31536000" always;
add_header X-Content-Type-Options nosniff;

Limit on IP location/api/v1/{
limit_req zone=per_ip burst=40 nodelay;
proxy_set_header X-Request-Id $req_id;
proxy_set_header X-Client-Ip $remote_addr;
proxy_read_timeout 5s;
proxy_connect_timeout 1s;
proxy_pass http://payments_v1;
}

Canary traffic by header location/api/v2/{
if ($http_x_canary = "1") { proxy_pass http://payments_v2; }
proxy_pass http://payments_v1;
}
}
}

13. 2 Envoy (JWT, rate limit, retries, outlier)

yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0. 0. 0. 0, port_value: 443 } }
filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config:
name: local_route virtual_hosts:
- name: payments domains: ["api. example. com"]
routes:
- match: { prefix: "/api/v1/payments" }
route:
cluster: payments_v1 timeout: 5s retry_policy:
retry_on: "connect-failure,refused-stream,5xx,retriable-status-codes"
num_retries: 2 per_try_timeout: 2s http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. jwt_authn. v3. JwtAuthentication providers:
main:
issuer: "https://auth. example. com/"
remote_jwks: { http_uri: { uri: "https://auth. example. com/.well-known/jwks. json" } }
forward: true rules:
- match: { prefix: "/api/" }
requires: { provider_name: "main" }
- name: envoy. filters. http. ratelimit
- name: envoy. filters. http. router clusters:
- name: payments_v1 connect_timeout: 0. 5s type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: { cluster_name: payments_v1, endpoints: [{ lb_endpoints: [{ endpoint: { address: { socket_address: { address: payments, port_value: 8080 }}}}]}] }
outlier_detection: { consecutive_5xx: 5, interval: 5s, base_ejection_time: 30s }

14) Chèques-feuilles

Avant la sortie de l'itinéraire

• Schéma d'authentification (JWT/JWKS, clés, cache TTL).
• Timouts/Retrai/Idempotence personnalisés.
• Limites : per-IP, per-key, per-route ; quotas de partenaires.
• Validation du schéma demandes/réponses.
• Logs et traçages avec 'trace-id', masques PII.
• SLO/alertes et dashboard.
• La géo-réglementation/conformité/âge a été vérifiée.

Transactions et paiements

• Itinéraire intelligent PSP : règles, priorités, faussaire.
• Same-method est vérifié sur le bord.
• États transparents et codes d'erreur pour le client (sans code PSP brut).

Versions

• Canary/AB et kill-switch, plan de retour.
• Trafic Shadow sur la nouvelle version, comparaison des métriques.
• Essais de charge et objectifs p95.

15) Métriques de qualité (minimum)

Disponibilité/SLO le long des itinéraires ; error rate 5xx/4xx.
Latitude p50/p95/p99 (externe et interne).
Retry/timeout/circuit événements (niveau de bruit).
Cache hit-ratio et économie RPS.
Rate-limit hits et requêtes abandonnées.
PSP-routing KPIs : succès, TtW, pourcentage de faussaire, commission.

16) Anti-modèles

Une limite totale pour tout.
Retraits « instantanés » sans jitter (augmentation de la tempête).
Confiance dans 'X-Forwarded-For' sans normalisation et liste de proxy de confiance.
Temps forts sans compter p95 (faux positifs).
Transformations difficiles qui brisent la compatibilité.
Logs avec PII/PAN/secrets.
Mélange des API internes et externes sous un seul domaine/politique.

17) Modèles de réponses et erreurs (microcopy)

429 Too Many Requests : "La limite des demandes est atteinte. Répétez dans N secondes ou augmentez le quota dans le bureau du partenaire"

401/403 : "Le token n'est pas valide/a expiré. Reconnectez-vous

408/504 : "Le service répond plus longtemps que prévu. La demande n'a pas été acceptée"

Idempotency-conflict : « Une requête avec une telle Idempotency-Key a déjà été traitée (statut : succès/refus) ».

18) Processus de mise en œuvre (par étapes)

1. Modèle d'itinéraire : carte des domaines/chemins/régions.
2. Stratégies de sécurité : TLS/mTLS, WAF, authN/Z, clés/JWKS.
3. Fiabilité : Timeouts, Retrai, idempotency, circuit-breaker.
4. Observabilité : logs/métriques/tracés, corelation.
5. Cache/perf : edge/micro-cache, compression, connect pools.
6. Itinérance de paiement : règles, tests, surveillance.
7. Sorties : canary/shadow, kill-switch, plan de retour.
8. Conformité/géo : filtres de pays, stockage de données, âge.

La trappe finale

Périmètre strict (TLS/mTLS, WAF, limites) + trafic contrôlé (retraits, circuit, canary).
La validation et les transformations au bord → moins de défauts « à l'intérieur ».
L'observation avec trace-id et les masques PII n'est pas une option, mais une norme.
Le routage intelligent des paiements et la conformité géo sont essentiels pour iGaming.
Versioning et politique de privation - prévisibilité pour les partenaires.