Latencia

Resumen

La latencia es el tiempo que pasa entre una acción y su respuesta observable. En una API puede ser desde que llega un request hasta que sale la respuesta. En una app puede ser desde que el usuario toca un botón hasta que ve feedback. En un sistema de IA puede incluir red, armado de prompt, inferencia, herramientas, streaming y renderizado.

Importa porque la latencia es experiencia de usuario y también señal operativa. Un sistema puede tener buen throughput y aun así sentirse lento. Peor: el promedio puede verse sano mientras una parte de usuarios sufre esperas enormes. Por eso se miran percentiles como p95 o p99, no solo promedios.

Alcance y supuestos

Este paquete cubre latencia como concepto de arquitectura y operación: tiempo de respuesta, latencia percibida, percentiles, tail latency, timeouts y decisiones prácticas para reducir espera.

No cubre tuning profundo de redes, benchmarking formal, diseño completo de observabilidad ni optimización de bajo nivel. Asume que entiendes requests, respuestas, APIs, servicios y métricas básicas de producción.

Modelo mental

Piensa en una fila de cafetería. El promedio puede decir que atienden en 2 minutos, pero si cada décimo cliente espera 12 minutos, la experiencia real no es "rápida" para todos. El promedio esconde la cola larga.

En sistemas pasa lo mismo. La latencia promedio responde "cuánto tarda típicamente", pero p95 responde "qué tan mal le va al 5% más lento". Para usuarios, ese 5% puede ser justo el checkout, una consulta crítica o el primer render de la página.

La latencia no es una sola cosa. Puede venir de red, base de datos, cold start, locks, colas, payload grande, proveedor externo, modelo lento, reintentos o renderizado. Optimizar sin separar esas fuentes suele mover el problema en vez de resolverlo.

Uso práctico

Usa latencia como métrica de diseño cuando una espera afecta experiencia, costo o confiabilidad:

• ✅ Medir p50, p95 y p99 de un endpoint crítico antes de optimizar.
• ✅ Definir timeout y fallback para llamadas a proveedores externos.
• ✅ Usar caching, streaming o trabajo asíncrono cuando el usuario no necesita esperar todo.
• ❌ No optimices solo el promedio: puede esconder tail latency dolorosa.
• ❌ No confundas throughput con latencia; procesar mucho por segundo no garantiza que cada request responda rápido.

Ejemplo trabajado: medir p95 antes de tocar infraestructura

Supón que un endpoint /checkout parece rápido porque el promedio es 180 ms. Pero algunos usuarios reportan esperas largas. Antes de cambiar servidores, conviene mirar percentiles:

type RequestTiming = {
  route: string;
  durationMs: number;
};

const timings: RequestTiming[] = [
  { route: "/checkout", durationMs: 120 },
  { route: "/checkout", durationMs: 160 },
  { route: "/checkout", durationMs: 180 },
  { route: "/checkout", durationMs: 210 },
  { route: "/checkout", durationMs: 950 },
];

function percentile(values: number[], percentileValue: number) {
  const sorted = [...values].sort((left, right) => left - right);
  const index = Math.ceil((percentileValue / 100) * sorted.length) - 1;

  return sorted[Math.max(0, index)];
}

const checkoutDurations = timings
  .filter((timing) => timing.route === "/checkout")
  .map((timing) => timing.durationMs);

const p50 = percentile(checkoutDurations, 50);
const p95 = percentile(checkoutDurations, 95);

En ese ejemplo, p50 puede ser aceptable, pero p95 expone el caso lento. La siguiente pregunta no es "¿compramos más CPU?", sino "¿qué componente produce esos 950 ms?".

Posibles acciones:

1. Separar latencia por tramo: red, app, base de datos, proveedor externo y render.
2. Agregar timeout para dependencias lentas.
3. Cachear lecturas repetidas si la frescura lo permite.
4. Mover trabajo no crítico a una cola.
5. Usar streaming o feedback temprano para mejorar latencia percibida.
6. Reducir payload, joins o llamadas secuenciales innecesarias.

La decisión correcta depende de dónde está la espera. Optimizar latencia es diagnosticar la ruta crítica, no solo hacer el código "más rápido".

Evidencia

• Google SRE Book, Monitoring Distributed Systems trata la latencia como una de las señales centrales de monitoreo y advierte que una fracción pequeña de requests puede experimentar tiempos mucho peores que el promedio.
• Google SRE Workbook, Implementing SLOs muestra SLOs de latencia con múltiples umbrales, por ejemplo porcentajes de requests bajo 100 ms y 400 ms.
• MDN Web Docs, Understanding latency define latencia de red como el tiempo que tarda una solicitud en viajar desde quien la hace hasta quien responde.