Latencia vs. Throughput

Cuando hablamos de rendimiento de sistemas, dos métricas aparecen constantemente: latencia y throughput. Muchos desarrolladores las usan como si fueran lo mismo, pero no lo son. Y confundirlas puede llevarte a optimizar lo incorrecto.

Un sistema puede ser extremadamente rápido para un solo usuario (baja latencia) pero colapsar cuando llegan mil usuarios simultáneos (throughput insuficiente). O puede manejar miles de usuarios (alto throughput) pero cada uno experimenta respuestas lentas (alta latencia).

En este artículo, explicaré la diferencia vital entre ambas métricas, cómo medirlas, y qué estrategias aplicar según el problema que realmente tienes.

¿Qué es la latencia?

La latencia es el tiempo que tarda una operación en completarse desde la perspectiva de un solo usuario o request. Es la demora entre “envío una petición” y “recibo la respuesta”.

Ejemplos:

Tiempo que tarda una página en cargar (desde click hasta contenido visible)
Tiempo que tarda una API en responder (desde request hasta response)
Tiempo que tarda una transacción en confirmarse

Métricas típicas:

P50 (mediana): La mitad de las peticiones son más rápidas que este valor
P95: El 95% de las peticiones son más rápidas que este valor
P99: El 99% de las peticiones son más rápidas que este valor

La latencia se mide en milisegundos (ms) o segundos. Un sistema con “baja latencia” responde rápido. Un sistema con “alta latencia” se siente lento para el usuario.

¿Qué es el throughput?

El throughput es la cantidad de trabajo que un sistema puede procesar en un período de tiempo. Es cuántas operaciones completas por segundo (o por minuto) puede manejar el sistema cuando hay múltiples usuarios o cargas concurrentes.

Ejemplos:

Requests por segundo que puede manejar una API
Transacciones por minuto que procesa una base de datos
Usuarios simultáneos que puede soportar una aplicación

Métricas típicas:

Requests por segundo (RPS)
Transacciones por segundo (TPS)
Usuarios concurrentes soportados

El throughput se mide en operaciones por unidad de tiempo. Un sistema con “alto throughput” puede manejar mucha carga. Un sistema con “bajo throughput” se satura cuando llegan muchos usuarios.

La diferencia en la práctica

Imagina una carretera:

Latencia: Cuánto tiempo tarda un coche en ir del punto A al punto B. Si la carretera está vacía, puede ser muy rápido (baja latencia). Si hay un accidente o un cuello de botella, puede tardar mucho (alta latencia).

Throughput: Cuántos coches pueden pasar por la carretera en una hora. Una carretera de un solo carril tiene menor throughput que una de cuatro carriles. Cuando hay demasiados coches, se forman atascos (el sistema se satura).

Puedes tener:

Baja latencia y bajo throughput: Una carretera vacía de un solo carril. Cada coche va rápido, pero pocos pasan por hora.
Alta latencia y alto throughput: Una carretera muy transitada de muchos carriles. Cada coche va lento, pero muchos pasan por hora.
Baja latencia y alto throughput: El ideal. Carretera amplia y fluida.
Alta latencia y bajo throughput: Lo peor. Carretera estrecha y congestionada.

¿Cuál es tu problema real?

Antes de optimizar, debes identificar si tu problema es de latencia o de throughput.

Problema de latencia

Síntomas:

Un solo usuario reporta que la aplicación es lenta
Las respuestas tardan mucho incluso con poca carga
El tiempo de respuesta (P95, P99) es alto
La aplicación “se siente lenta” en uso normal

Causas típicas:

Consultas a base de datos lentas (falta de índices, N+1 queries)
Lógica de negocio pesada en el request
Llamadas a servicios externos lentos
Código no optimizado (algoritmos ineficientes)
Red o I/O bloqueante

Estrategias:

Optimizar consultas (índices, evitar N+1)
Caché para datos frecuentemente accedidos
Procesamiento asíncrono (no bloquear el request)
Reducir round-trips (menos llamadas, datos agregados)
Profiling para encontrar cuellos de botella reales

Problema de throughput

Síntomas:

La aplicación funciona bien con pocos usuarios
Con muchos usuarios simultáneos, todo se ralentiza o falla
Timeouts bajo carga
Errores 503 o “service unavailable” en picos
La CPU o memoria se saturan

Causas típicas:

Un solo servidor o proceso no puede manejar la carga
Base de datos que no escala
Conexiones limitadas (pool agotado)
Recursos compartidos que se convierten en cuello de botella
Falta de escalabilidad horizontal

Estrategias:

Escalar horizontalmente (más instancias)
Load balancing
Colas para desacoplar y suavizar picos
Escalar la base de datos (réplicas de lectura, sharding)
Optimizar recursos compartidos (connection pooling, límites)

No son mutuamente excluyentes

Un sistema puede tener ambos problemas. O optimizar uno puede empeorar el otro.

Ejemplo: Añadir caché puede reducir la latencia (menos consultas a BD) pero si el caché no está bien dimensionado o hay muchos writes, el throughput puede no mejorar o incluso empeorar.

Ejemplo: Añadir más servidores (escalar horizontalmente) puede mejorar el throughput, pero si cada request sigue siendo lento por una consulta pesada, la latencia sigue siendo alta.

Por eso es crucial medir primero y definir objetivos. ¿Qué es inaceptable hoy? ¿Latencia alta para usuarios? ¿Saturación bajo carga? Eso define qué optimizar.

Cómo medir

Latencia:

APM (Application Performance Monitoring): Datadog, New Relic, etc.
Logs con timestamps en entrada y salida de requests
Métricas de tu framework (middleware que mida tiempo de respuesta)
Herramientas de carga que reporten percentiles (k6, Artillery, wrk)

Throughput:

Pruebas de carga: cuántos RPS soporta antes de degradarse
Métricas de infraestructura: CPU, memoria, conexiones bajo carga
Límites observados en producción (picos de tráfico reales)

Objetivos típicos:

Latencia P95 < 200 ms para APIs
Latencia P99 < 500 ms
Throughput: soportar X RPS según tu negocio (pico esperado + margen)

Mi perspectiva personal

He visto equipos optimizar throughput (añadir servidores, más réplicas) cuando el problema real era latencia: una consulta mal escrita que tardaba 2 segundos. Los usuarios seguían quejándose de lentitud.

Y he visto equipos obsesionarse con reducir latencia (caché por everywhere, optimizaciones prematuras) cuando el problema real era throughput: en Black Friday el sistema colapsaba porque no había suficientes instancias ni base de datos preparada para ese pico.

La clave es medir, definir el problema, y luego elegir la estrategia. Latencia y throughput son conceptos distintos, con soluciones distintas. Entender la diferencia te permite no solo optimizar mejor, sino comunicar mejor con negocio y operaciones: “Tenemos un problema de throughput” o “Tenemos un problema de latencia” lleva a acciones muy diferentes.

En sistemas bien diseñados, se trabaja ambos: latencia aceptable por request y capacidad suficiente (throughput) para el número esperado de usuarios. Pero cuando algo falla, saber si falla por lentitud individual o por saturación te da el mapa para arreglarlo.