Puerta de enlace y enrutamiento API

1) El rol de la puerta de enlace API en la arquitectura

• Enruta las solicitudes (en ruta/headers/geo/peso/versión).
• Protege el perímetro (TLS/mTLS, WAF, DDoS, rate limits, authN/Z).
• Gestiona el tráfico (canario/AB, shadow/mirror, circuito breaker, retraídas, timeouts).
• Estandariza protocolos (NAT/gRPC/WebSocket), encabezados, códigos.
• Observa (registros, métricas, trazados, corulación).
• Transforma y valida (JSON/XML, normalización, validación schema).

Para iGaming, también es geo-compliance (bloqueos por país/edad), routing inteligente de pago y políticas de juego responsable en el borde.

2) Opciones de enrutamiento

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' → backend de afiliados; 'Accept: application/grpc'.
Geo-routing: por IP/ASN/país (GDPR/prohibiciones locales, latency).
Weighted/Canary: '90%' a la antigua, '10%' a la nueva versión; retroceso rápido.
Claim-routing: по `JWT. claims. tier/role/region '(por ejemplo, high-roller → límites premium).
Failover: activo-activo/activo-pasivo entre centros de datos/nubes y PSP.

3) Seguridad perimetral

TLS everywhere: TLS 1. 2 + en el exterior, mTLS en el interior (shlyuz↔servisy).
OAuth2/JWT: validación de firma, auditoría de 'amb/nbf/aud/scope', rotación JWKS; caché de validación con TTL.
HMAC: firma de cuerpos para webhooks/pagos.
Claves API: para clientes del sistema; asociamos con cuotas/roles.
WAF: reglas básicas (injection, protocol anomalies), tamaño corporal, lista de países deny.
Protección DDoS: conexión limitada, cookies SYN, rate-limit en IP/clave/endpoint.
Zero-Trust: políticas de mandato (SPIFFE/SPIRE, identidades de servicios), el principio de los derechos más pequeños.
Privacidad: editar PII en los logs, enmascarar PAN/IBAN, política de retención.

4) Límites, cuotas y protección contra los bursts

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

• Burst + sustentado (por ejemplo, '50 rps burst', '10 rps sustain').
• Retry-Budget y protección Slow-Loris (tiempos de lectura).
• Quota por días/mes para socios.

5) Transformaciones y validación

Normalizar títulos (trace-id, locale, client-id).
Request/Response-mapping (campos/códigos, ocultar atributos internos).
La validación de Schema (OpenAPI/JSON Schema) antes del proxy es una falla temprana de 4xx.
Compression/' Accept-Encoding ', caching (ver más abajo).

6) Caché y rendimiento

Edge-caché para guías, metadatos públicos, confecciones (TTL, 'ETag '/' If-None-Match').
Micro-caché de 1-5 s en caliente GET (reduce la carga máxima).
Negative-cache breve (en 404/empty) - cuidado.
Hedging-requests y solicitudes de réplicas competitivas a p95> umbral.

7) Taimouts, retrayas, estabilidad

Timeout: connect/read/write por separado; p95 puntos de referencia razonables.
Retraídas: métodos idempotent (GET/PUT) c backoff + jitter; retry-budget.
Idempotencia POST: 'Idempotency-Key' + deduplicación en el lado del servicio/gateway.
Circuit-Breaker: por error/latencia; muestras half-open.
Bulkhead/Pool-aislamiento por Apstrim.

8) Versificación e interoperabilidad

• URI: '/v1/... '(rutas simples pero «ruidosas»).
• Header/Content-Negotiation: `Accept: application/vnd. app. v2+json`.
• Feature-flags/server capability - para compatibilidad de minor-change.

Política: SemVer, ventana de soporte (por ejemplo, 'v1' = 12-18 meses), gráfico de descripciones, respuestas compatibles con extensiones (agregar campos no rompe).

9) Observabilidad y control de calidad

La correlación: 'traceparent '/' x-request-id' es obligatoria; Vamos hacia abajo.
OpenTelemetry: métricas de RPS/p50/p95/p99/5xx/4xx, saturación, retry/circuito de eventos.
Registros: JSON estructurales; enmascarando PII; niveles por códigos.
Sampling Tracks: básico 5-10% + objetivo para errores/lento.
SLO/alertas: por rutas/clientes (aptime, latency, error).

10) Gestión del tráfico de lanzamientos

Azul-Verde: conmutación DNS/LB.
Canarias: peso/segmentos (región, socio, rol).
Shadow/Mirror: copia del tráfico a la nueva versión sin responder al cliente.
Kill-switch: una bandera para desactivar rápidamente el Apstream/Fichi problemático.

11) Enrutamiento de pagos inteligentes (iGaming)

Reglas de selección de PSP: geo, moneda, cantidad, riesgo-score, disponibilidad, comisión.
Failover PSP: transición automática a '5xx/timeout'.
Regla Same-method: devoluciones/conclusiones a través del método original - validación en el borde.
Idempotencia de pago: clave en 'userId + amount + currency + purpose'.
Transparencia de ETA: la pasarela añade estados y razones de rechazo (no códigos del PSP).

12) Políticas y cumplimiento de las regiones cruzadas

Filtros geo: listas blancas/negras de países, límites de edad, ranges IP.
Datos de residentes: enrutamiento a clústeres regionales (GDPR/leyes locales).
Registros y TTL: almacenamiento por región, anonimización automática.

13) Ejemplos de configuraciones

13. 1 NGINX (enrutamiento + límite + 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) Hojas de cheques

Antes de la liberación de la ruta

• Esquema de autenticación (JWT/JWKS, claves, caché TTL).
• Los taimautas/retraídas/idempotencia están configurados.
• Límites: per-IP, per-key, per-route; Cuotas de socios.
• Validación del esquema de consultas/respuestas.
• Logs y tracks con 'trace-id', máscaras PII.
• SLO/alertas y dashboard.
• Se verificaron las reglas geográficas/cumplimiento/edad.

Transacciones y pagos

• Smart Routing PSP: reglas, prioridades, Feover.
• Same-method se verifica en el borde.
• Estados transparentes y códigos de error para el cliente (sin código PSP en bruto).

Versiones

• Canary/AB y kill-switch, plan de retroceso.
• Tráfico de sombras a la nueva versión, comparación de métricas.
• Pruebas de carga y p95 objetivos.

15) Métricas de calidad (mínimo)

Availability/SLO a lo largo de las rutas; error rate 5xx/4xx.
Latency p50/p95/p99 (externa e interna).
Retry/timeout/circuito de eventos (nivel de ruido).
Cache hit-ratio y ahorro de RPS.
hits de rate-limit y solicitudes descartadas.
PSP-routing KPIs: aciertos, TtW, porcentaje de failover, comisión.

16) Anti-patrones

Un límite común «para todo».
Retrés «instantáneos» sin jitter (intensificación de la tormenta).
Confianza en 'X-Forwarded-For' sin normalización y lista de proxy de confianza.
Tiempos de espera sólidos sin tener en cuenta p95 (falsos positivos).
Transformaciones duras que rompen la compatibilidad.
Registros con PII/PAN/secretos.
Mezcla de la API interna y externa bajo un solo dominio/política.

17) Patrones de respuesta y error (microcopia)

429 Too Many Requests: "Se ha alcanzado el límite de solicitudes. Repita después de N segundos o aumente la cuota en la oficina del compañero"

401/403: "El token es inválido/caducado. Vuelva a iniciar sesión"

408/504: "El servicio cumple más de lo esperado. No se aceptó la solicitud"

Idempotency-conflict: «La solicitud con tal Idempotency-Key ya ha sido procesada (estado: éxito/rechazo)».

18) Proceso de implementación (por pasos)

1. Modelo de rutas: mapa de dominios/rutas/regiones.
2. Políticas de seguridad: TLS/mTLS, WAF, authN/Z, claves/JWKS.
3. Fiabilidad: temporizadores, retraídos, idempotency, circuit-breaker.
4. Observabilidad: logs/métricas/tracks, corulación.
5. Caché/perforación: edge/micro-cache, compresión, conector-pools.
6. Routing de pago: reglas, pruebas, monitoreo.
7. Lanzamientos: canary/shadow, kill-switch, plan de reversión.
8. Cumplimiento/geo: filtros de país, almacenamiento de datos, edad.

Parche final

Perímetro estricto (TLS/mTLS, WAF, límites) + tráfico gestionado (retraídas, circuitos, canarios).
Validación y transformaciones en el borde → menos defectos «en el interior».
La observabilidad con trace-id y máscaras PII no es una opción, sino un estándar.
Pagos de enrutamiento inteligente y compliance geo: son críticos para iGaming.
La versionización y la política de despilfarro son previsibles para los socios.