Tecnología e Infraestructura → Latency y optimización de la respuesta de API

Latency y optimización de la respuesta de API

1) Qué es «latency» y por qué es importante

Latency - retardo total de la solicitud: red (DNS + TCP + TLS + RTT), balanceador/gateway, aplicación, DB/caché/cola, integraciones externas. Para los negocios, la P95/P99 es crítica, no la media: es la «cola» la que colapsa UX, CR y SLO.

• 'SLI _ latency _ P95 = P95 (tiempo _ respuesta)' en 5/30 minutos
• 'SLI _ latency _ P99 = P99 (tiempo _ respuesta)'
• 'SLI _ queue _ time = P95 (hora _ en _ cola _ worker)'
• 'SLI _ ext _ call _ P95 = P95 (latencia _ proveedores _ externos)'

2) Mapa de las fuentes de retraso (y dónde excavar)

1. Red y protocolos: DNS, TCP handshakes, TLS, head-of-line (HTTP/1. 1), pérdida de paquetes, BBR/ECN.
2. Gateway/balancer: cheques de salud lentos, timeouts inválidos, pods calientes.
3. Aplicación: bloqueos, GC/stop-the-world, sincronizado I/O, contenido.
4. Repositorios: consultas de BD lentas, sin índices, páginas frías.
5. Servicios externos: PSP/KYC, API de terceros (estrechos SLA).
6. Colas y jobs de fondo: workers re-cargados, no backpressure.
7. Caché/edge: errores de caché, TTL débil, discapacidad inválida.

3) Red y protocolos

3. 1 DNS/TCP/TLS

DNS prefetch/preconnect en el frente, IP de larga vida a PSP.
Keep-Alive/connection pooling en clientes; en el servidor: agregue las conexiones.
TLS: resumption/Session Tickets, un moderno paquete de cifrado; evite la 0-RTT para las operaciones idempotentes inseguras.
TCP: desactive Nagle ('TCP _ NODELAY') para chats/paquetes pequeños; tune 'initial window', habilite BBR cuando corresponda.

3. 2 HTTP/2 и HTTP/3

HTTP/2: multiplexación reduce los bloqueos HOL de HTTP/1. 1; vigile las prioridades de los flujos.
HTTP/3/QUIC: a continuación, el impacto de las pérdidas/RTT; útil en la red móvil/internacional.
Compresión de encabezado: HPACK/QPACK, pero mantenga un tamaño de título razonable.

3. 3 Equilibrio/enrutamiento

Locality-aware (zonalidad), EWMA/least-request contra instancias «calientes».
Rellenar sesiones - sólo si hay un estado; de lo contrario, stateless + caché/sesión compartida.

4) Formatos, carga útil, compresión

Comprimir: Brotli (texto), Gzip como fallback; formatos binarios: Protobuf/Avro para gRPC/API internas.
Reducir payload: campos selectivos ('fields =...'), paginación, GET condicionales (ETag/If-None-Match), respuestas delta.
GraphQL: queries persistidos, prohibición de fragmentos «gordos», límites de profundidad y complejidad.
Evitar N + 1: joynas/precomposición, endpoints batch para agregados.

5) Taimautas, retraídas, idempotencia

Timeout por cadena: cliente <gateway <appa <almacenamiento/llamada externa.
Retrés con backoff + jitter, sólo para errores temporales; exponer budgets en retraídas.
Idempotencia: clave/señal de consulta + guardar el resultado; los retiros no deben duplicar las operaciones (especialmente las finanzas).
Circuit Breaker: abrir cuando se degrade; hedged/backup requests para «colas» (enviar duplicado a través de P95).

6) Colas, asincronía y retroceso

No bloquee la ruta sincrónica: operaciones pesadas (análisis KYC, informes) - en el fondo.
Backpressure: limitar el consumo de la cola, fijar el paralelismo.
Batching/coalescing: combine operaciones pequeñas (por ejemplo, actualizar balances con agregación).
Outbox/Inbox: entrega garantizada de eventos en caso de fallos.

7) Aplicación: rantims y pools

Grupos de conexiones al BD/caché/NTTR; limítelos para no «estrangular» el backend.
JVM: perfilar GC (G1/ZGC), evitar alocaciones grandes; .NET - ThreadPool/async; Node. js - no bloquee el loop de eventos, saque la CPU pesada.
Python: controladores asíncronos (asyncpg/http px), uvloop; Tareas de CPU a través de worker-pool.
Warm-up: calentar JIT/caches, "warm pools' de las instancias a los picos.

8) Bases de datos y cachés

Índices y planes: regular 'EXPLAIN', auto-vacío/análisis, límite de escáneres.
Conexión pooling (PgBouncer/Multiplexing), transacciones cortas.
Estrategias de caché: read-through, write-through/write-behind; TTL + discapacidad por eventos.
Charding/réplicas: leyendo desde ranuras, las «teclas calientes» son cachés locales (near-cache).

9) Almacenamiento en caché y edge

CDN/edge para estáticos/directorios, caché de respuestas API (si es seguro) por 'Cache-Control', 'ETag'.
Stale-while-revalidate y stale-if-error para resistencia UX.
Distribución geo: el RRR/región más cercana reduce el RTT.

10) Patrones arquitectónicos contra colas P99

Solicitudes Hedged: duplique una solicitud lenta a otra instancia después del umbral.
Request collapsing: una petición «principal» a la DB, el resto está esperando el resultado (evita tormentas).
Priorización: Operaciones críticas/VIP - Agrupación/prioridad dedicada.
Degradación Graceful: corte los campos/widgets menores cuando esté sobrecargado.

11) Confecciones (aproximadamente)

11. 1 NGINX (temporización/compresión)

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 (cliente)

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) Observabilidad: medir correctamente

Métricas RED/USE + Tracks OTel: 'trace _ id' a través de las API externas de gateway-service-DB.
Etiquetas individuales: 'api _ version', 'region', 'partner', 'endpoint'.
Dashboards: P50/P95/P99, queue time, error mix, retry rate, cache hit.
Synthetics de los países objetivo/ASN (TR/BR/EU) y por caminos críticos (reg→depozit, payout).

• Core API: 'P95 ≤ 250ms', 'P99 ≤ 500ms' (30 días)
• Procesamiento de webhook PSP: 'P99 ≤ 60s' con retrés
• Freshness del catálogo: 'P95 lag ≤ 30s'

13) FinOps и latency

Los milisegundos cuestan dinero: valora $/ms de ganar en CR/ARPPU.
Right-sizing: más rápido ≠ más caro siempre; los formatos/caché competente son más baratos y más rápidos.
Egress/edge: CDN reduce el RTT y el costo del tráfico saliente de la región.

14) Lista de verificación de optimización (paso a paso)

1. Colocar SLO y medir las colas (P95/P99) por endpoints/regiones/socios.
2. Habilite las conexiones HTTP/2/3, TLS, de larga vida.
3. Apriete y adelgace las respuestas: Brotli/Gzip, campos bajo petición, paginación, ETag.
4. Configure los temporizadores/retraídos/rompedores; agregue idempotencia.
5. Caché/edge: hit-rate y TTL correctos; modos stale.
6. DB: índices, planes, grupos, réplicas; eliminar N + 1.
7. Asíncrono pesado: colas, batcheo, retroceso.
8. Hedge/collapse/priority para rutas críticas.
9. Warm-up y skaling predictivo a los picos (torneos/partidos).
10. Sintética y alertas en P99 y queue time; ruibarbo regular.

15) Anti-patrones

Un tiempo de espera global «para todo» y retraídas incontrolables (DDOS de sí mismo).
Verter sesiones sin necesidad de → nodos calientes.
JSON grande sin compresión y filtros de campo.
Llamadas sincrónicas a API externas lentas en la «ruta de acceso».
Ausencia de índices/límites en la DAB; N + 1 en ORM.
No hay caché/edge y ETag; Respuestas completas constantes.
Una mezcla de errores empresariales y técnicos en un carrito de compras «retraído».

16) Contexto iGaming/Fintech: notas prácticas

Reg→depozit (CR): prioridad de rutas, piscina separada, 'P99 ≤ 500ms'; degradación - desactivar las «decoraciones» de IU.
Integración PSP: límites de concarrensi, retraídas por códigos de tiempo, warm connects, egress-IP regionales.
Operaciones VIP: grupo/prioridad garantizada, evitación de colas comunes.
Torneos/eventos: skale predictivo, caché calentado, prefetch.
Reporting: async y SLA en freshness, no bloquea la ruta de acceso.

Resultado

La optimización latency es una disciplina de equilibrio: red (HTTP/2/3, TLS), protocolos y caché, temporizadores/retras con idempotencia, DB/caché, patrones asíncronos y observabilidad P95/P99. Al enfocarse en las colas y eliminar las «gargantas estrechas», estabilizará la respuesta, mejorará la conversión y reducirá el costo de milisegundos, donde realmente afecta el negocio.