Modal vincula cada sessão a 1 contêiner e preserva o contexto na reconexão

Um bot de voz conversa com o usuário, a conexão cai e o usuário se reconecta, mas chega a um processo que não sabe nada sobre ele. Para a infraestrutura do servidor, isso pode ser um balanceamento de carga normal. Para o produto, é uma conversa interrompida. A Modal apresentou o Sticky Sessions: um mecanismo que direciona as solicitações de uma mesma sessão ao mesmo contêiner e dimensiona a infraestrutura de acordo com o número de sessões ativas.

Na prática, o desenvolvedor pode manter o estado temporário junto do código em execução: o contexto de um agente de voz, o estado de um decodificador de reconhecimento de fala ou uma sala de jogo compartilhada. Na reconexão, a solicitação volta ao local onde esse estado já está, enquanto a sessão continuar ativa.

Por que um WebSocket não basta

Imagine um serviço de treinamento para entrevistas com IA de voz. O agente e o processamento de áudio são executados em um contêiner, que também mantém o estado da conversa atual. O usuário troca o Wi-Fi pela internet móvel. A conexão precisa ser restabelecida, mas o produto deve continuar a entrevista de onde parou.

Como explica a Modal, um WebSocket em suas Web Functions está vinculado a uma invocação específica de função. Após a desconexão, uma nova invocação é criada e pode chegar a outro contêiner. Portanto, o WebSocket, por si só, não resolve o problema de retornar ao processo anterior.

Uma alternativa é limitar a aplicação a um único contêiner. Assim, as solicitações não têm outro destino possível, mas a solução do problema de roteamento também elimina a possibilidade de escalabilidade horizontal. O Modal Servers também oferece roteamento pelo cabeçalho Modal-Affinity-Routing-Key, mas sem garantia estrita: o contêiner pode ser interrompido ou substituído.

O Sticky Sessions introduz um vínculo mais rigoroso durante a vida da sessão. Isso é especialmente útil para aplicações com Gradio e Streamlit, nas quais o estado do usuário está ligado a um processo específico do servidor. O desenvolvedor deixa de precisar manter todo o serviço em uma única instância para garantir a continuidade dos fluxos de cada usuário.

Como a solicitação encontra o processo certo

Para ativar o mecanismo, a classe do Modal Server recebe o decorador @modal.sessioned(); em seguida, uma sessão é criada pelo SDK ou pela API HTTP. No exemplo apresentado pela empresa, a chamada sessions.start(idle_timeout=600) retorna um objeto com um token. O cliente envia esse token no cabeçalho Modal-Authorization nas solicitações seguintes.

O token é assinado e contém as informações necessárias para o roteamento. O proxy o valida e encaminha a solicitação ao contêiner ao qual a sessão pertence. Com isso, o proxy não precisa manter uma tabela separada e consistente de correspondências entre sessões e contêineres em todas as suas instâncias.

Um mesmo token pode ser compartilhado com vários participantes de uma sala. Por exemplo, dois usuários se conectam ao mesmo chat e trabalham com um estado mantido em um único processo. A reconexão leva o participante de volta à mesma sala enquanto ela existir. Como o token concede acesso à sessão, a aplicação deve tratá-lo como uma credencial.

A unidade de dimensionamento também muda. Um contêiner aceita uma quantidade configurada de sessões simultâneas. Quando não há vagas, as novas sessões aguardam o encerramento das existentes ou a disponibilização de um contêiner adicional. O dimensionamento automático considera as sessões ativas e a fila, pois uma conversa já iniciada não pode ser transferida arbitrariamente para um processo vizinho.

O que verificar antes da implementação

A principal limitação: fixar uma rota não garante a preservação dos dados em caso de falha do contêiner. A publicação descreve a continuidade das solicitações dentro de uma sessão, mas não promete recuperar seu estado em memória após uma falha. Históricos de conversas, resultados de trabalho e outros dados importantes ainda precisam ser persistidos separadamente se o produto tiver de sobreviver a esses eventos.

Há também a questão da distribuição de carga. Duas sessões podem consumir quantidades diferentes de recursos: uma conversa curta por texto e um fluxo contínuo de áudio geram cargas muito distintas. Por isso, o número de sessões por contêiner precisa ser definido de acordo com o cenário real de uso. O mecanismo não transfere automaticamente uma sessão existente que consome muitos recursos para equilibrar a carga.

Para equipes que trabalham com agentes de voz ou interfaces que dependem da memória do processo, vale verificar o comportamento durante quedas de conexão e avaliar o custo de sessões prolongadas. O Sticky Sessions preenche uma lacuna específica de infraestrutura: permite combinar a adição automática de contêineres com o retorno do usuário a um processo já em execução. O plano de recuperação de falhas continua sendo parte da arquitetura da aplicação.