En sistemas distribuidos, la latencia es uno de los factores que más impacto tiene en la experiencia del usuario y en la carga de los equipos. Un sistema puede estar "arriba", pero si responde tarde, para el cliente está caído igual.
¿Qué es realmente la latencia?
Es el tiempo que tarda una operación en completarse: desde que se hace una solicitud hasta que se recibe la respuesta. En un sistema distribuido, ese tiempo se reparte entre:
- Red y hops intermedios
- Procesamiento de cada servicio involucrado
- Consultas a bases de datos y sistemas externos
- Transformaciones, validaciones y reglas de negocio
Cuando el sistema crece, la latencia deja de ser un número y se vuelve un presupuesto.
Latencia como presupuesto de diseño
En plataformas serias, la pregunta no es "¿cuánto demora?", sino: "¿cuánta latencia podemos permitirnos y cómo la distribuimos?".
📊 Ejemplo: Presupuesto de latencia (500ms total)
- Definir tiempos máximos por operación crítica.
- Asignar "cuotas de latencia" a servicios y llamadas externas.
- Evitar recorridos innecesarios y dependencias en cadena.
- Decidir qué puede ser síncrono y qué debe ser asíncrono.
⚠️ Cómo se manifiestan los problemas de latencia
- Usuarios que "sienten" el sistema lento aunque no haya errores.
- Incremento de timeouts y reintentos que multiplican la carga.
- Spikes de CPU y memoria en momentos de alta demanda.
- Incidentes intermitentes difíciles de reproducir.
Buenas prácticas en sistemas distribuidos
- Medir latencia end-to-end, no solo por componente.
- Correlacionar latencia con volumen, horarios y tipos de operación.
- Usar cachés de forma estratégica, no como parche genérico.
- Aplicar timeouts, circuit breakers y backpressure.
- Revisar diseño funcional: a veces el problema no es técnico, es del flujo.
Un sistema rápido no es el que tiene más hardware, sino el que usa bien cada milisegundo. Entender la latencia es entender cómo realmente vive y respira tu plataforma.
