Latencia intermitente en la migración de un servicio de pedidos
Una tienda en línea migró su servicio de pedidos de un servidor único a dos servidores idénticos detrás de un balanceador de capa 4. Cada servidor mantiene en memoria el carrito de compras del usuario y una caché local de sesión. Desde la migración, ~7% de los usuarios reportan que su carrito aparece vacío en la pantalla de pago; el error ocurre de forma intermitente y nunca en la primera petición. Los registros del balanceador muestran que las conexiones se distribuyen casi 50/50 entre ambos servidores. La base de datos compartida no muestra errores y los tiempos de respuesta por servidor son normales (120-180 ms). El equipo propone duplicar la memoria de cada servidor y reiniciar el balanceador para 'limpiar el estado'.
1. ¿Cuál es la causa más probable del carrito vacío y por qué la solución propuesta no la resuelve?
Read the worked answer
La causa es que el estado de sesión vive en la memoria local de cada servidor y el balanceador de capa 4 no garantiza afinidad de sesión (sticky sessions). El usuario inicia sesión en el servidor A, pero una petición posterior cae en el servidor B, que no conoce su carrito; por eso el fallo es intermitente y no ocurre en la primera petición (cuando aún no hay estado que perder).
Duplicar memoria y reiniciar el balanceador no corrige la causa: el estado sigue siendo local y la distribución 50/50 seguirá enviando peticiones al servidor equivocado. Reiniciar solo vacía el estado y puede agravar el síntoma.
Diagnóstico correcto: revisar si el balanceador tiene persistencia por IP o cookie; verificar en los logs si las peticiones de un mismo usuario llegan a ambos servidores. La solución de fondo es externalizar la sesión (almacén compartido como Redis o base de datos) o configurar afinidad de sesión, sabiendo que la afinidad se rompe si un servidor falla.
2. El equipo insiste en solo activar 'sticky sessions' en el balanceador. Evalúa esa opción frente a externalizar el estado de sesión, considerando que el servicio debe sobrevivir a la caída de un servidor.
Read the worked answer
Las sticky sessions son un parche rápido: reducen el síntoma porque cada usuario queda ligado a un servidor, pero introducen un punto de fallo. Si el servidor A cae, todos los usuarios ligados a él pierden su carrito, y el balanceador tendrá que reasignarlos a B, que no tiene su estado. Además, la afinidad por IP falla con NAT y redes móviles, y la afinidad por cookie requiere que el balanceador inspeccione capa 7.
Externalizar el estado (Redis, base de datos o almacén distribuido) desacopla la sesión del servidor: cualquier instancia puede atender a cualquier usuario y la caída de un nodo solo implica reintentar en el otro. El costo es una dependencia adicional y latencia de red por petición, mitigable con caché y réplicas.
Dado el requisito de tolerancia a fallos, la decisión correcta es externalizar el estado; las sticky sessions pueden usarse como medida temporal mientras se implementa, no como solución definitiva.