Modal vincula cada sesión a 1 contenedor y conserva el contexto al reconectarse

Un bot de voz conversa con un usuario, la conexión se interrumpe y el usuario vuelve a conectarse, pero llega a un proceso que no sabe nada de él. Para la infraestructura del servidor, puede ser un reparto de carga normal. Para el producto, es una conversación rota. Modal ha presentado Sticky Sessions: un mecanismo que dirige las solicitudes de una misma sesión al mismo contenedor y escala la infraestructura según el número de sesiones activas.

En la práctica, permite a los desarrolladores mantener el estado temporal junto al código en ejecución: el contexto de un agente de voz, el estado de un decodificador de reconocimiento de voz o una sala de juego compartida. Al reconectarse, la solicitud vuelve al lugar donde ya se encuentra ese estado, siempre que la sesión siga activa.

Por qué un WebSocket no basta

Imaginemos un servicio para practicar entrevistas con IA de voz. El agente y el procesamiento de audio se ejecutan en un contenedor, que también almacena el estado de la conversación actual. El usuario pasa de Wi-Fi a datos móviles. Hay que restablecer la conexión, pero el producto debe continuar la entrevista desde donde se quedó.

Como explica Modal, un WebSocket en sus Web Functions está vinculado a una invocación concreta de una función. Tras la desconexión se genera una nueva invocación, que puede llegar a otro contenedor. Por tanto, un WebSocket por sí solo no resuelve el problema de volver al proceso anterior.

Una solución alternativa consiste en limitar la aplicación a un solo contenedor. Así, las solicitudes no tienen otro destino posible, pero al resolver el problema de enrutamiento también se pierde la posibilidad de escalar horizontalmente. Modal Servers también dispone de enrutamiento mediante la cabecera Modal-Affinity-Routing-Key, aunque funciona sin garantías estrictas: el contenedor puede detenerse o ser sustituido.

Sticky Sessions introduce una vinculación más estricta durante la vida de la sesión. Esto resulta especialmente útil en aplicaciones con Gradio y Streamlit, donde el estado del usuario está ligado a un proceso concreto del servidor. El desarrollador ya no tiene que mantener todo el servicio en una única instancia para dar continuidad a los flujos de cada usuario.

Cómo encuentra una solicitud el proceso correcto

Para activar el mecanismo, se marca la clase de Modal Server con el decorador @modal.sessioned() y después se crea una sesión mediante el SDK o la API HTTP. En el ejemplo de la empresa, la llamada sessions.start(idle_timeout=600) devuelve un objeto con un token. El cliente envía ese token en la cabecera Modal-Authorization en las solicitudes posteriores.

El token está firmado y contiene la información necesaria para el enrutamiento. El proxy lo valida y envía la solicitud al contenedor al que pertenece la sesión. De este modo, el proxy no necesita mantener una tabla independiente y coherente de correspondencias entre sesiones y contenedores en todas sus instancias.

Un mismo token puede compartirse con varios participantes de una sala común. Por ejemplo, dos usuarios se conectan al mismo chat y trabajan con un estado alojado en un único proceso. Al reconectarse, el participante vuelve a la misma sala mientras esta siga activa. El token da acceso a la sesión, por lo que la aplicación debe tratarlo como una credencial.

También cambia la unidad de escalado. Un contenedor admite un número configurado de sesiones simultáneas. Cuando no quedan plazas, las nuevas sesiones esperan a que terminen las existentes o a que esté listo un contenedor adicional. El escalado automático tiene en cuenta las sesiones activas y la cola, ya que una conversación en curso no puede trasladarse arbitrariamente a un proceso vecino.

Qué comprobar antes de implementarlo

La principal limitación: fijar una ruta no garantiza que los datos sobrevivan al fallo de un contenedor. La publicación describe la continuidad de las solicitudes dentro de una sesión, pero no promete recuperar su estado en memoria después de un fallo. El historial de conversaciones, los resultados del trabajo y otros datos importantes deben seguir guardándose por separado si el producto necesita sobrevivir a estos incidentes.

También hay que considerar el reparto de carga. Dos sesiones pueden consumir cantidades distintas de recursos: una conversación breve de texto y un flujo continuo de audio generan cargas muy diferentes. Por eso, el número de sesiones por contenedor debe ajustarse al caso de uso real. El mecanismo no traslada automáticamente una sesión existente que consume muchos recursos para equilibrar la carga.

Para un equipo que desarrolla agentes de voz o interfaces que dependen de la memoria del proceso, es una oportunidad para comprobar el comportamiento ante cortes de conexión y evaluar el coste de las sesiones prolongadas. Sticky Sessions cubre una carencia concreta de infraestructura: permite combinar la incorporación automática de contenedores con el regreso del usuario a un proceso que ya está en ejecución. El plan de recuperación ante fallos sigue formando parte de la arquitectura de la aplicación.