Cómo prevenir problemas de latencia en la arquitectura

La latencia de un sistema se decide en gran parte durante el diseño. Cada componente que interviene en una solicitud (red, balanceador, servicio, base de datos, proveedor externo) agrega su propio tiempo, y el usuario percibe la suma de todos. Corregir la latencia con el sistema en producción suele exigir cambios de arquitectura que cuestan mucho más que preverla desde el inicio. Esta guía reúne las decisiones de diseño que más influyen y la forma de verificarlas antes de publicar.

Fijar un presupuesto de latencia

El primer paso consiste en definir cuánto tiempo puede tardar cada operación crítica y repartirlo entre los componentes que participan. Sin ese reparto, cada equipo optimiza lo suyo sin saber cuánto margen le corresponde. El siguiente ejemplo es hipotético y supone un objetivo de 300 ms para una consulta frecuente.

El objetivo debe expresarse en percentiles (por ejemplo, P95 y P99) y no en promedios, porque el promedio oculta las solicitudes lentas que los usuarios sí notan. Cuando un componente excede su parte durante las pruebas, se sabe de inmediato dónde intervenir.

Distancia y número de saltos

La distancia impone un mínimo que ninguna optimización elimina. La luz recorre la fibra a unos 200.000 km por segundo, de modo que un viaje de ida y vuelta entre Norteamérica y Europa suele situarse entre 60 y 100 ms antes de ejecutar cualquier lógica. Por eso conviene ubicar los servicios cerca de los usuarios y mantener juntos los componentes que se llaman entre sí con frecuencia, en la misma región y, cuando sea posible, en la misma zona de disponibilidad.

El número de saltos pesa tanto como la distancia. Un servicio que realiza diez llamadas secuenciales a otros servicios para armar una respuesta acumula diez veces el costo de red, de establecimiento de conexión y de serialización. Agrupar datos en una sola llamada, reutilizar conexiones persistentes y servir contenido estático desde una red de distribución reducen ese costo sin tocar la lógica de negocio.

Latencia de cola y llamadas en paralelo

Cuando una solicitud depende de varias llamadas a otros servicios, la probabilidad de que alguna sea lenta crece con el número de llamadas. Si cada servicio responde lento en el 1 % de los casos y una solicitud depende de 100 llamadas, la probabilidad de que al menos una sea lenta es 1 − 0,99¹⁰⁰, cerca de 63 %. Un comportamiento marginal en cada componente se convierte así en la experiencia habitual del usuario. Este efecto, descrito por Dean y Barroso en el artículo "The Tail at Scale", obliga a reducir el número de dependencias por solicitud, a fijar límites de tiempo por llamada y, en operaciones de lectura, a considerar solicitudes redundantes con cancelación de la más lenta.

Utilización y colas

La latencia no crece de forma lineal con la carga. En un modelo simplificado de cola, el tiempo de respuesta equivale al tiempo de servicio dividido entre uno menos la utilización. Con 50 % de utilización el tiempo de respuesta es el doble del tiempo de servicio, con 80 % es cinco veces mayor y con 90 % llega a diez veces. Un sistema que opera cerca de su capacidad máxima responde de forma errática ante pequeños aumentos de tráfico. Por eso la capacidad se dimensiona con holgura, y el umbral de utilización aceptable se determina con pruebas de carga y no por intuición.

Tiempos de espera, reintentos y fallas parciales

Todas las llamadas entre componentes necesitan un tiempo de espera definido y menor que el del componente que las invoca. Sin esa regla, una dependencia lenta mantiene ocupados los recursos del servicio que la llama y la lentitud se propaga hacia arriba.

Los reintentos mal configurados agravan el problema. Cuando un servicio degradado recibe, además de su tráfico normal, los reintentos de todos sus clientes, la carga se multiplica y la recuperación se retrasa. Las prácticas habituales son limitar el número de reintentos, aplicar espera exponencial con variación aleatoria (jitter) y usar interruptores de circuito que dejen de llamar a un servicio que está fallando durante un período definido.

Acceso a datos y caché

La base de datos suele aportar la mayor parte del tiempo de una solicitud. Los problemas más frecuentes son las consultas repetidas por cada elemento de una lista (el patrón conocido como N+1), la ausencia de índices en los filtros más usados y un tamaño inadecuado del conjunto de conexiones. Se recomienda fijar un número máximo de consultas por solicitud y revisarlo durante las pruebas.

1 consulta   → lista de pedidos
N consultas  → detalle de cada pedido
Resultado    → N + 1 consultas por solicitud

La caché reduce la latencia de los datos de lectura frecuente y que cambian poco, siempre que se defina su vigencia y se proteja contra la avalancha de solicitudes simultáneas cuando un dato expira. Las réplicas de lectura descargan la base principal, pero introducen un retraso de replicación que el diseño debe tolerar.

Trabajo asíncrono fuera de la ruta crítica

Las tareas que el usuario no necesita para recibir la respuesta, como enviar notificaciones, generar reportes o actualizar sistemas secundarios, se publican en una cola y se procesan aparte. De esta forma la solicitud principal solo incluye el trabajo que determina su resultado, y las demoras de esos procesos no se reflejan en el tiempo de respuesta.

Verificación antes de producción

Un diseño con buena latencia en el papel debe comprobarse con pruebas de carga que usen tráfico y volúmenes de datos representativos, y que midan percentiles por operación contra el presupuesto definido. Conviene incorporar estas pruebas al proceso de entrega, para detectar regresiones en cada versión. El trazado distribuido permite ver cuánto aporta cada componente a cada solicitud, y la inyección controlada de latencia en dependencias confirma que los tiempos de espera, los reintentos y los interruptores se comportan como se diseñaron.

Decisiones por cada parte

Imágenes generadas con IA