Latencia baja, ¿sistema mejor? El costo oculto de optimizar el rendimiento

Por Martinez Henry

Resumen (TL;DR)

La latencia es una métrica crítica, pero reducirla a toda costa tiene un precio que pocas veces se discute abiertamente. En este artículo exploramos qué es la latencia, cómo medirla correctamente y por qué optimizarla sin criterio puede derivar en sistemas más costosos, más complejos y más difíciles de mantener. La conclusión es simple: la mejor latencia no es la más baja, sino la más adecuada para el problema que estás resolviendo.

📑 Tabla de Contenido

  1. Latencia: la métrica que todos miran (pero pocos cuestionan)

  2. Milisegundos que cuestan usuarios, dinero y confianza

  3. No todo tiempo de respuesta dice la verdad

  4. El arsenal clásico para hacer sistemas más rápidos

  5. La factura oculta de bajar la latencia

  6. No todo endpoint merece ser ultrarrápido

  7. La mejor latencia no es la más baja, es la más adecuada

Introducción: La brecha del conocimiento

Dentro del atributo de calidad de rendimiento (performance), podemos encontrar la latencia, que como lo define Rick Kazman en su libro Arquitectura de Software en la Práctica, es: “El tiempo transcurrido entre la llegada del estímulo y la respuesta del sistema al mismo.”

Si extrapolamos esta definición a un escenario de una API, podemos decir que la latencia es el tiempo que tarda en responder la aplicación desde que el cliente realiza una petición hasta que recibe y puede visualizar la respuesta.

Pero ¿cómo podemos medirla realmente? ¿Un tiempo de respuesta bajo es un indicio de que mi aplicación es óptima? ¿Significa que está trabajando de forma eficiente?

Sin duda, el tiempo de respuesta es un factor muy importante en las aplicaciones del mundo actual. Sin embargo, no debería ser el único indicador de calidad o eficiencia. En este artículo discutiremos por qué no solo debemos preocuparnos por reducir la latencia, sino también por entender los efectos colaterales que pueden aparecer cuando la optimizamos al máximo.

Optimizar la latencia es importante, pero hacerlo sin entender sus implicaciones puede llevar a sistemas más costosos, complejos y difíciles de mantener. Veamos el por qué.

Latencia: la métrica que todos miran (pero pocos cuestionan)

¿Qué es realmente la latencia?

La latencia es el tiempo que transcurre entre que un sistema recibe una solicitud y devuelve una respuesta. Parece simple, pero detrás de esa definición se esconde una cadena de eventos: tiempo de red (ida), procesamiento en el servidor, consultas a bases de datos o servicios externos, serialización de la respuesta y tiempo de red (vuelta). Cada uno de esos pasos suma.

En un sistema distribuido típico, la latencia no es un número único sino el resultado acumulado de docenas de componentes. Por eso, cuando alguien dice “mi API responde en 50ms”, vale la pena preguntarse: ¿en qué condiciones? ¿con qué carga? ¿desde qué región?

Latencia en APIs y sistemas modernos

En la práctica, muchos equipos asumen que menor latencia siempre significa mejor sistema. Es comprensible: es una métrica visible, fácil de comunicar y de comparar. Pero esa simplicidad puede ser engañosa.

Optimizar la latencia no es una decisión gratuita: suele implicar costos técnicos, económicos y arquitectónicos que no siempre se consideran. Un sistema que responde en 10ms en lugar de 100ms puede estar consumiendo el doble de memoria, duplicando datos, aumentando la complejidad del código y elevando la factura de infraestructura.

Milisegundos que cuestan usuarios, dinero y confianza

Impacto en experiencia de usuario

La latencia afecta directamente la percepción que un usuario tiene de un sistema. La psicología del rendimiento es clara al respecto: los usuarios perciben demoras a partir de los 100ms y comienzan a perder el hilo de la interacción alrededor de los 1000ms. Por encima de los 10 segundos, la atención se pierde por completo.

Pero más allá de los números, una aplicación lenta transmite inestabilidad. Incluso si el sistema funciona correctamente por debajo, el usuario interpreta la lentitud como un error, una falla o falta de confiabilidad. La percepción de calidad está directamente atada al tiempo de respuesta.

Impacto en negocio y métricas

El impacto de la latencia no se queda en la experiencia de usuario: se traduce en dinero. Estudios ampliamente referenciados en la industria muestran que incrementos de latencia de tan solo 100ms pueden reducir las tasas de conversión de forma medible. Por eso no es raro que muchas decisiones de arquitectura estén guiadas por la necesidad de reducir milisegundos.

Más allá de la conversión, la latencia afecta el cumplimiento de SLAs (acuerdos de nivel de servicio). Si un equipo se compromete con tiempos de respuesta específicos y los incumple de forma sostenida, las consecuencias pueden ir desde penalidades contractuales hasta pérdida de clientes.

La latencia importa. Eso está fuera de discusión. El problema aparece cuando se convierte en la única métrica que guía las decisiones de arquitectura.

No todo tiempo de respuesta dice la verdad

Promedio vs percentiles

Uno de los errores más comunes al medir latencia es usar el promedio como indicador principal. El promedio es útil para tener una idea general, pero oculta los casos extremos: los usuarios que sistemáticamente reciben respuestas lentas.

Imagina un sistema donde el 95% de las peticiones se resuelven en 20ms, pero el 5% restante tarda más de 2 segundos. El promedio podría rondar los 120ms y parecer razonable, pero esos usuarios en el extremo tienen una experiencia terrible.

Por eso, la industria trabaja con percentiles:

  • p50 (mediana): el tiempo que la mitad de las peticiones no supera.
  • p95: el tiempo que el 95% de las peticiones no supera. Útil para detectar degradaciones.
  • p99: el tiempo que el 99% de las peticiones no supera. Crítico en sistemas de alta exigencia.

Reducir el promedio de latencia no siempre mejora la experiencia real del usuario. En muchos casos, los percentiles altos son los que definen la percepción del sistema. Un p99 alto indica que hay usuarios que sufren la aplicación, aunque el promedio sea bueno.

Latencia del cliente vs del servidor

Otro factor que distorsiona la medición es confundir la latencia del servidor con la latencia que el usuario realmente percibe. El servidor puede responder en 30ms, pero si el cliente tarda 200ms adicionales por red, procesamiento del navegador o renderizado, el usuario percibe 230ms.

Medir solo la latencia del servidor puede dar una falsa sensación de eficiencia. La latencia real es la que experimenta el usuario desde que hace clic hasta que puede interactuar con el resultado.

Cómo medirla correctamente

Una medición honesta de latencia debe considerar:

  • Percentiles, no solo promedio. Al menos p50, p95 y p99.
  • Latencia end-to-end, no solo en el servidor.
  • Condiciones de carga realistas. La latencia en reposo no es representativa de producción.
  • Segmentación por endpoint. No todos los flujos tienen el mismo perfil de latencia.
  • Variabilidad temporal. La latencia puede cambiar según el horario, la carga de la base de datos o la saturación de la red.

Herramientas como Prometheus, Grafana, Datadog o incluso logs bien estructurados permiten construir esta visión más completa.

El arsenal clásico para hacer sistemas más rápidos

Cuando se detecta latencia alta, existen varias estrategias comunes para reducirla. Estas técnicas son válidas y necesarias, pero cada una introduce costos que muchas veces no se analizan en profundidad.

Caché

El caché es probablemente la técnica más utilizada para reducir latencia. La idea es simple: si una respuesta es costosa de calcular, se almacena temporalmente para servirla de forma inmediata en solicitudes posteriores. Se puede implementar en memoria (Redis, Memcached), en disco, a nivel de HTTP o en el propio cliente.

El problema es que el caché introduce un nuevo estado que hay que gestionar: ¿cuándo expira? ¿cómo se invalida? ¿qué pasa si los datos cambian antes de que expire?

Paralelismo y asincronía

Ejecutar operaciones en paralelo permite reducir el tiempo total de una solicitud cuando hay tareas independientes. Por ejemplo, si una API necesita consultar tres servicios distintos, hacerlo de forma paralela en vez de secuencial puede reducir el tiempo de respuesta a la duración de la operación más lenta en lugar de la suma de todas.

La asincronía, por su parte, permite liberar recursos mientras se espera una operación de I/O, mejorando el throughput del sistema.

Optimización de base de datos

Gran parte de la latencia de una aplicación se origina en las consultas a la base de datos. Estrategias como agregar índices apropiados, reescribir consultas ineficientes, usar paginación, limitar los campos seleccionados o evitar el problema N+1 pueden tener un impacto enorme sin necesidad de cambiar la arquitectura.

CDN y precálculo

Para contenido estático o respuestas que no cambian por usuario, distribuirlo geográficamente mediante una CDN (Content Delivery Network) reduce la latencia de red al servir los datos desde un nodo más cercano al cliente.

El precálculo lleva esta idea más lejos: en lugar de calcular una respuesta en tiempo de solicitud, se calcula con anticipación y se almacena lista para ser servida. Útil para reportes, recomendaciones o vistas agregadas que son costosas de generar al vuelo.

La factura oculta de bajar la latencia

Reducir la latencia rara vez es gratis. En la mayoría de los casos, implica intercambios que afectan otras dimensiones del sistema.

Mayor consumo de memoria

Muchas optimizaciones de latencia consisten básicamente en intercambiar tiempo por memoria. El caché es el ejemplo más claro: para evitar recalcular o re-consultar algo, se guarda en memoria. Cuanto más agresiva es la estrategia de caché, más memoria se consume.

Lo mismo aplica a la materialización de vistas o la duplicación de datos: se almacena información en múltiples lugares o formatos para que cada consulta pueda responder más rápido sin necesidad de hacer transformaciones costosas en tiempo real.

Esto no es malo por definición, pero tiene un límite. La memoria tiene costo económico y físico, y su gestión incorrecta puede derivar en problemas más graves que la latencia original.

Mayor uso de CPU

Reducir milisegundos de respuesta suele implicar gastar más ciclos de procesamiento. La compresión de respuestas reduce el tiempo de transferencia pero requiere CPU para comprimir y descomprimir. La serialización eficiente con formatos binarios como Protobuf es más rápida en red pero más costosa de procesar que JSON simple. El precálculo transfiere trabajo del momento de la solicitud al momento de la escritura o a un job en background, distribuyendo el costo pero sin eliminarlo.

Más complejidad arquitectónica

Cada optimización introduce nuevos puntos de falla y aumenta el costo de mantenimiento. Agregar Redis implica operar y monitorear un nuevo servicio. Implementar procesamiento asíncrono con colas introduce complejidad en el manejo de errores, reintentos y orden de procesamiento. Los sistemas de replicación o CDN requieren estrategias de invalidación y sincronización.

Un sistema simple que responde en 200ms puede ser más mantenible y confiable que uno complejo que responde en 20ms. La complejidad tiene un costo silencioso que se paga en tiempo de desarrollo, debugging y onboarding de nuevos integrantes.

Costo en infraestructura

Más caché significa más nodos de memoria. Más replicación significa más instancias de base de datos. Más paralelismo puede significar más workers o más instancias de cómputo. El CDN tiene su propio modelo de costos por transferencia. Todo esto se traduce en una factura de infraestructura más alta.

En sistemas de gran escala, reducir latencia de p99 de 500ms a 100ms puede requerir multiplicar por tres el gasto mensual en infraestructura. La pregunta que vale la pena hacerse es: ¿ese delta de rendimiento justifica ese costo?

Riesgos de consistencia

En muchos sistemas, reducir latencia implica aceptar cierto grado de inconsistencia temporal. El caché puede devolver datos desactualizados si la invalidación no está bien implementada. Los datos precalculados pueden no reflejar el estado más reciente del sistema. La replicación eventual significa que distintos nodos pueden tener versiones diferentes de los mismos datos durante un período de tiempo.

Estos escenarios no siempre son aceptables. En contextos donde la integridad de los datos es crítica —transacciones financieras, inventario en tiempo real, sistemas médicos— aceptar inconsistencia para ganar velocidad puede tener consecuencias graves.

No todo endpoint merece ser ultrarrápido

Dónde la latencia sí es crítica

No todas las operaciones tienen el mismo impacto en el negocio, por lo que no todas requieren la misma inversión en optimización.

Hay flujos donde la latencia es directamente crítica porque afecta la decisión del usuario o el flujo de negocio:

  • Login y autenticación: una demora aquí genera fricción en el primer contacto con el sistema.
  • Checkout y pago: cada segundo de espera en el proceso de compra aumenta la probabilidad de abandono.
  • Búsqueda: el usuario espera resultados inmediatos; la demora rompe la interacción.
  • Operaciones en tiempo real: dashboards, feeds, notificaciones, chat.

En estos casos, invertir en optimización tiene retorno directo y medible.

Optimización guiada por negocio

Sin embargo, hay operaciones donde la latencia no es tan relevante porque el usuario entiende o acepta que son lentas:

  • Reportes administrativos que se generan una vez al día.
  • Exportaciones masivas de datos a CSV o Excel.
  • Sincronizaciones en background con sistemas externos.
  • Procesos de cierre contable o consolidación de datos.

Optimizar estos flujos con el mismo nivel de agresividad que un endpoint de búsqueda no aporta valor proporcional. El usuario que descarga un reporte espera algunos segundos; es parte del contexto de uso.

Optimizar sin priorizar suele llevar a sistemas costosos sin beneficios reales. La clave está en identificar qué operaciones afectan la experiencia del usuario o el negocio de forma directa, y enfocar el esfuerzo ahí.

La mejor latencia no es la más baja, es la más adecuada

Equilibrio entre performance y costo

La latencia importa. Medir bien importa más. Pero optimizar sin entender los trade-offs puede llevar a sistemas que responden rápido y se caen con frecuencia, que son costosos de operar y difíciles de mantener, o que son eficientes en condiciones normales y frágiles bajo carga.

La arquitectura de software es, en esencia, un ejercicio de equilibrio. Cada decisión que toma es un intercambio entre atributos de calidad: rendimiento, mantenibilidad, escalabilidad, disponibilidad, costo. No hay una arquitectura perfecta; hay arquitecturas adecuadas para un contexto específico.

Antes de embarcarse en una optimización de latencia, vale la pena responder:

  1. ¿Cuál es la latencia actual y en qué percentil estoy midiendo?
  2. ¿Qué impacto real tiene esa latencia en el negocio o en el usuario?
  3. ¿Cuál es el objetivo de latencia? ¿Cómo sabré que llegué?
  4. ¿Qué trade-offs introduce la optimización que estoy considerando?
  5. ¿El costo de esos trade-offs es aceptable para este sistema?

Reflexión final

En ingeniería de software, el objetivo no es construir el sistema más rápido posible, sino el más adecuado para el problema que estamos resolviendo.

Reducir la latencia puede ser la decisión correcta. Pero también puede ser una optimización prematura que introduce complejidad innecesaria, consume recursos que no están justificados y distrae el esfuerzo de problemas más relevantes.

La próxima vez que alguien proponga una optimización de latencia, la mejor pregunta no es “¿cuánto más rápido quedaría?” sino “¿qué estamos dispuestos a pagar por esa velocidad?”.

Evidencia

La investigación moderna sobre el impacto de la latencia se articula alrededor de los Core Web Vitals, el marco de métricas de experiencia de usuario que Google formalizó a partir de 2020 y que desde 2021 influye en el posicionamiento en búsqueda:

  • Vodafone UK (2021): Al mejorar su métrica de LCP (Largest Contentful Paint) en un 31%, Vodafone observó un incremento del 8% en ventas y una reducción del 15% en usuarios que abandonaban el proceso de checkout. El caso está documentado en los estudios de impacto de Core Web Vitals publicados por Google.
  • KIWI.com (2022): La plataforma de viajes redujo su INP (Interaction to Next Paint) en un 50%, lo que se correlacionó con un aumento del 20% en la tasa de conversión. Es uno de los casos más citados para justificar la optimización de interactividad.
  • HTTP Archive Web Almanac 2023: El análisis anual del estado de la web documentó que más del 40% de los sitios analizados no alcanzaban los umbrales de “bueno” en LCP, y que los sitios con peor rendimiento en Core Web Vitals mostraban consistentemente tasas de rebote más altas. El reporte es una referencia anual de acceso libre.
  • INP como Core Web Vital (Google, marzo 2024): Google reemplazó la métrica FID (First Input Delay) por INP (Interaction to Next Paint) como señal oficial de interactividad. El cambio refleja que una sola demora no representa bien la experiencia del usuario; lo relevante es la latencia percibida a lo largo de toda la interacción.

Estos datos justifican la preocupación por la latencia. Sin embargo, son números agregados de sistemas a escala masiva. Para la mayoría de los sistemas, el impacto real depende del contexto específico: tipo de usuario, naturaleza de la operación y sensibilidad del flujo de negocio.

Cierre: Hacia una Ingeniería Consciente

La latencia es una herramienta de diagnóstico, no un objetivo en sí mismo. Perseguirla sin criterio lleva a decisiones técnicas costosas que resuelven problemas de rendimiento mientras crean problemas de complejidad, costo y consistencia.

Una ingeniería consciente implica medir bien antes de optimizar, entender los trade-offs antes de aplicar una solución y priorizar el esfuerzo según el impacto real en el negocio y en el usuario.

No todo sistema necesita ser rápido en todo momento. Los mejores sistemas no son los que tienen la latencia más baja, sino los que tienen la latencia correcta en los lugares que importan, con un costo de operación y mantenimiento que el equipo puede sostener en el tiempo.

Esa es la diferencia entre optimizar por costumbre y diseñar con propósito.

Referencias e Inspiraciones: