API-Gateway und Routing

1) Die Rolle des API-Gateways in der Architektur

• Routing-Anfragen (nach Pfad/Header/Geo/Gewicht/Version).
• Schützt den Umfang (TLS/mTLS, WAF, DDoS, rate limits, authN/Z).
• Verwaltet den Datenverkehr (Canary/AB, Shadow/Mirror, Circuit Breaker, Retrays, Timeouts).
• Standardisiert Protokolle (REST/gRPC/WebSocket), Header, Codes.
• Beobachtet (Protokolle, Metriken, Traces, Korrespondenzen).
• Transformiert und validiert (JSON/XML, Normalisierung, Schema-Validation).

Für iGaming geht es auch um Geo-Compliance (Länder-/Alterssperren), Payment Smart Routing und die Politik des verantwortungsvollen Spielens am Rand.

2) Routing-Optionen

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'.
Geo-Routing: per IP/ASN/Land (DSGVO/lokale Verbote, Latenz).
Gewichtet/Kanarisch: „90%“ auf die alte, „10%“ auf die neue Version; schnelles Zurückrollen.
Claim-routing: по `JWT. claims. tier/role/region'(z.B. High-Roller → Premium-Limits).
Failover: Asset-Asset/Asset-Asset zwischen Rechenzentrum/Cloud und PSP.

3) Perimeter Sicherheit

TLS everywhere: TLS 1. 2 + auf der Außenseite, mTLS innen (shlyuz↔servisy).
OAuth2/JWT: Signaturprüfung, Audit 'exp/nbf/aud/scope', JWKS-Rotation; Validierungs-Cache mit TTL.
HMAC: Unterschrift der Körper für Webhooks/Zahlungen.
API-Schlüssel: für Systemclients; mit Quoten/Rollen verknüpfen.
WAF: Grundregeln (Injektion, Protokoll Anomalien), Körpergröße, Deny-Liste der Länder.
DDoS-Schutz: Verbindungslimitierung, SYN-Cookies, Rate-Limit pro IP/Schlüssel/Endpunkt.
Zero-Trust: Mandatspolitik (SPIFFE/SPIRE, Dienstleistungsidentitäten), Prinzip der geringsten Rechte.
Datenschutz: PII-Bearbeitung in Protokollen, PAN/IBAN-Maskierung, Aufbewahrungsrichtlinie.

4) Limits, Quoten und Burst-Schutz

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

• Burst + nachhaltig (z.B. '50 rps burst', '10 rps sustain').
• Retry-Budget und Slow-Loris-Schutz (Lese-Timeouts).
• Quote pro Tag/Monat für Partner.

5) Transformationen und Validierung

Titel normalisieren (trace-id, locale, client-id).
Request/Response-mapping (Felder/Codes, Ausblenden interner Attribute).
Schema-Validierung (OpenAPI/JSON-Schema) vor Proxy - früher 4xx-Ausfall.
Compression/' Accept-Encoding', caching (siehe unten).

6) Caching und Leistung

Edge-Cache für Nachschlagewerke, öffentliche Metadaten, Config (TTL, 'ETag '/' If-None-Match').
Micro-Cache 1-5 s auf Hot GET (reduziert die Spitzenlast).
Negativ-Cache kurz (bei 404/leer) - Vorsicht.
Hedging-Anfragen und kompetitive Anfragen an Replikate bei p95> Schwelle.

7) Timeouts, Retrays, Nachhaltigkeit

Timeouts: connect/read/write separat; vernünftige p95-Richtlinien.
Retrays: idempotent-Methoden (GET/PUT) c backoff + jitter; retry-budget.
POST-Idempotenz: 'Idempotency-Key' + Deduplizierung auf der Service-/Gateway-Seite.
Circuit-Breaker: durch Fehler/Latenz; halb-offene Proben.
Bulkhead/Pool-Isolierung nach Upstreams.

8) Versionierung und Kompatibilität

• URI: '/v1/...'(einfache, aber „laute“ Routen).
• Header/Content-Negotiation: `Accept: application/vnd. app. v2+json`.
• Feature-Flags/Server-Capability - für die Kompatibilität von Minor-Änderungen.

Richtlinie: SemVer, Support-Fenster (z.B. 'v1' = 12-18 Monate), Deprivationsgraph, kompatible Antworten bei Erweiterungen (Hinzufügen von Feldern - bricht nicht).

9) Beobachtbarkeit und Qualitätskontrolle

Korrelation: 'traceparent '/' x-request-id' ist obligatorisch; Wir rollen nach unten.
OpenTelemetry: Metriken für RPS/p50/p95/p99/5xx/4xx, Saturation, Retry/Circuit-Ereignisse.
Logs: strukturelle JSON; Wir maskieren PII; Ebenen nach Codes.
Sampling Traces: Basis 5-10% + Ziel für Fehler/langsam.
SLO/Alerts: nach Routen/Kunden (Aptime, Latency, Error).

10) Release Traffic Management

Blau-Grün: DNS/LB-Umschaltung.
Canary: Gewichtsanteil/Segmente (Region, Partner, Rolle).
Shadow/Mirror: Kopie des Datenverkehrs auf die neue Version ohne Antwort an den Client.
Kill-Switch: Ein Flag, um den problematischen Upstream/Fichi schnell zu deaktivieren.

11) Smart Payment Routing (iGaming)

PSP-Auswahlregeln: Geo, Währung, Betrag, Risikograd, Verfügbarkeit, Provision.
PSP-Fehler: Automatischer Übergang bei '5xx/timeout'.
Same-method-Regel: Retouren/Leads durch die ursprüngliche Methode - Überprüfung am Rand.
Zahlungsidempotenz: Schlüssel auf 'userId + amount + currency + purpose'.
ETA-Transparenz: Das Gateway fügt Fehlerstatus und Ursachen hinzu (nicht PSP-Codes).

12) Regionalübergreifende Richtlinien und Compliance

Geo-Filter: weiße/schwarze Länderlisten, Altersbeschränkungen, IP-Reinji.
Resident Data: Routing zu regionalen Clustern (DSGVO/lokale Gesetze).
Protokolle und TTL: Speicherung nach Region, automatische Anonymisierung.

13) Beispiele für Konfigurationen

13. 1 NGINX (Routing + Limit + Header)

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) Checklisten

Vor der Freigabe der Route

• Authentifizierungsschema (JWT/JWKS, Schlüssel, Cache TTL).
• Timeouts/Retrays/Idempotenz konfiguriert.
• Limits: per-IP, per-key, per-route; Quoten der Partner.
• Validierung des Abfrage-/Antwortschemas.
• Logs und Traces mit 'trace-id', PII-Masken.
• SLO/Alerts und Dashboards.
• Geo-Regeln/Compliance/Alter überprüft.

Transaktionen und Zahlungen

• PSP Smart Routing: Regeln, Prioritäten, Failover.
• Die Same-Methode wird am Rand geprüft.
• Transparente Status- und Fehlercodes für den Kunden (ohne PSP-Rohcode).

Veröffentlichungen

• Canary/AB und Kill-Switch, Rollback-Plan.
• Schattenverkehr zur neuen Version, Vergleich der Metriken.
• Belastungstests und p95 Ziele.

15) Qualitätskennzahlen (Minimum)

Verfügbarkeit/SLO auf Strecken; error rate 5xx/4xx.
Latency p50/p95/p99 (extern und intern).
Retry/Timeout/Circuit Ereignisse (Geräuschpegel).
Cache-Trefferverhältnis und RPS-Einsparungen.
Rate-Limit-Treffer und verworfene Abfragen.
PSP-Routing-KPIs: Erfolge, TtW, Failover-Prozentsatz, Provision.

16) Anti-Muster

Ein gemeinsames Limit „für alles“.
„Instant“ Retrays ohne Jitter (Sturmverstärkung).
Vertrauen in 'X-Forwarded-For' ohne Normalisierung und Liste der vertrauenswürdigen Proxies.
Feste Timeouts ohne p95 (False Positives).
Harte Transformationen, die die Kompatibilität brechen.
Logs mit PII/PAN/Secrets.
Mischen Sie interne und externe APIs unter einer Domäne/Richtlinie.

17) Antwortmuster und Fehler (Mikrokopie)

429 Too Many Requests: "Das Anforderungslimit ist erreicht. Wiederholen Sie nach N Sekunden oder erhöhen Sie die Quote im Büro des Partners"

401/403: "Token ungültig/abgelaufen. Melden Sie sich erneut an"

408/504: "Der Service antwortet länger als erwartet. Der Antrag wurde nicht angenommen"

Idempotency-conflict: „Eine Anfrage mit einem solchen Idempotency-Key wurde bereits bearbeitet (Status: Erfolg/Ablehnung)“.

18) Implementierungsprozess (in Schritten)

1. Routenmodell: Karte der Domains/Wege/Regionen.
2. Sicherheitsrichtlinien: TLS/mTLS, WAF, authN/Z, Schlüssel/JWKS.
3. Zuverlässigkeit: Timeouts, Retrays, Idempotency, Circuit-Breaker.
4. Beobachtbarkeit: Protokolle/Metriken/Traces, Korrelation.
5. Cache/Perf: Edge/Micro-Cache, Kompression, Connect-Pools.
6. Payment Routing: Regeln, Tests, Überwachung.
7. Releases: Canary/Shadow, Kill-Switch, Rollback-Plan.
8. Compliance/Geo: Länderfilter, Datenspeicherung, Alter.

Abschließender Spickzettel

Strikte Perimeter (TLS/mTLS, WAF, Limits) + Managed Traffic (Retrays, Circuit, Canary).
Validierung und Transformation am Rand → weniger Defekte „im Inneren“.
Die Beobachtbarkeit mit Trace-id und PII-Masken ist keine Option, sondern Standard.
Smart Payment Routing und Compliance-Geo - kritisch für iGaming.
Versionierung und Deprivationspolitik - Berechenbarkeit für Partner.