APIs HTTP dominam por décadas o paradigma de comunicação entre aplicações, é fácil cair na armadilha de tratar qualquer conexão como se fosse apenas mais uma requisição stateless, principalmente conexões stateful “sob HTTP”. Mas nem toda conexão é igual.

E conexões de longa duração merecem muito mais respeito.

O erro de subestimar o gRPC

Quantos projetos gRPC já fracassaram por partir da premissa equivocada de que, por usar HTTP/2, gRPC é apenas uma evolução natural do REST? A diferença fundamental é que o HTTP/2 habilita conexões multiplexadas e persistentes, o que muda drasticamente a forma como devemos gerenciar recursos, lidar com timeouts e projetar a resiliência do sistema.

Tratar gRPC como um simples request/response stateless é ignorar toda a complexidade (e o poder) de um canal persistente. Isso leva a falhas silenciosas, gargalos e uma gestão de recursos ineficiente.

Websockets e a armadilha do heartbeat

A história se repete com Websockets. Quantas aplicações mantêm milhares de conexões quase inativas, sustentadas apenas por heartbeats? Cada conexão viva consome memória, sockets e ciclos de CPU, mesmo que esteja ociosa. O resultado? Uma necessidade artificial de escalar horizontalmente, adicionando dúzias de máquinas apenas para manter um pool de conexões abertas.

O custo oculto das conexões long-lived mal gerenciadas é real e afeta diretamente a escalabilidade e a sustentabilidade financeira da solução.

Alternância dinâmica entre WebSocket e polling

Uma abordagem possível e adotada por sistemas modernos é a capacidade de alternar dinamicamente entre WebSocket e HTTP polling, de acordo com a demanda do sistema. Em cenários de baixa atividade ou inatividade temporária, adotar polling com intervalos inteligentes permite liberar recursos do servidor sem comprometer a funcionalidade. Esse mecanismo de fallback reduz drasticamente o consumo de memória, threads e sockets, especialmente quando milhares de clientes mantêm conexões que transmitem dados com pouca ou nenhuma frequência.

Por outro lado, quando o tráfego se intensifica ou a aplicação exige interações em tempo real — como notificações instantâneas, atualizações de dashboards ou interações colaborativas — a migração para WebSockets pode ser feita sob demanda, reestabelecendo o canal persistente de forma transparente para o usuário. Asssim a aplicação só volta a consumir conexões stateful quando realmente necessário.

Como dizia Milton Friedman, não existe almoço grátis! Não mesmo!

Essa transição inteligente exige um bom design no cliente e no servidor, além de métricas claras para guiar a troca entre os modos. Mais que uma otimização, esse tipo de adaptabilidade pode ser a chave para escalar com eficiência e previsibilidade em ambientes com picos e vales de uso.

Conexões stateful exigem testes integrados

Diferente de uma chamada stateless que é aberta e fechada em milissegundos, uma conexão stateful permanece viva, muitas vezes por minutos ou horas. Isso exige um entendimento profundo do ciclo de vida da conexão: como ela é aberta, mantida, recuperada após falhas e finalmente encerrada.

Testes integrados em cenários reais (incluindo falhas de rede, interrupções abruptas e reconexões) são essenciais para garantir que seu sistema não entre em estados inconsistentes ou consuma recursos indefinidamente.

TestContainers podem ajudar nessa jornada, tenho usado com sucesso para a implementação de testes integrados com Postgres e RabbitMQ, por exemplo.

A armadilha do consumo invisível de recursos

Conexões stateful consomem recursos continuamente: file descriptors, memória, CPU e slots de thread ou evento. Recursos limitado que, quando chegam ao seu limite produzem negação de serviço. Ou seja, demandam escala para que isso não ocorra. Se você não tem mecanismos de timeout, controle de conexões inativas, trocad e protocolo ou desconexão ativa, seu sistema inevitavelmente demandará escala precipitada, ou entrará em colapso sob carga.

Ao contrário do modelo stateless, onde cada interação é curta e previsível, as conexões persistentes criam um estado implícito no servidor. Isso limita drasticamente sua capacidade de escalar.

A complexidade da reconexão e do roteamento em ambientes orquestrados

Em ambientes baseados em containers, como Docker e Kubernetes, a expectativa de alta disponibilidade esconde frequentemente a complexidade envolvida na reconexão de clientes após falhas. Quando um pod morre ou um container é reiniciado, qualquer conexão stateful é perdida, exigindo que o cliente detecte a queda, implemente lógica de reconexão e restabeleça o estado — tudo isso sem afetar a experiência do usuário.

Além disso, mesmo com load balancers e service meshes sofisticados, como os baseados em Envoy, não há garantias de que o cliente será reconectado à mesma instância anterior, até porque ela pode nem existir mais. Para aplicações que mantêm estado local, como sessões em memória ou buffers de streaming, isso pode ser peculiarmente desafiador, gerando inconsistência, perda de dados ou necessidade de reprocessamento.

Projetar para esse cenário exige estratégia:

• adoção de stores distribuídos para estado (redis é uma solução possível)
• uso de sticky sessions (com moderação)
• e principalmente, preparar o cliente para falhas inevitáveis no ciclo de vida dos pods e containers.

A certeza que podemos ter é a de que falhará, portanto, precisamos tratar adequadamente esse comportamento esperado, previsível e natural de uma conexão stateful.

Conclusão

Conexões de longa duração oferecem vantagens significativas: baixa latência, bidirecionalidade e eficiência. Mas elas também trazem riscos sûtis, que se manifestam tardiamente em produção.

Ao lidar com sistemas distribuídos e de alto desempenho, precisamos projetar com consciência. Cada conexão é uma promessa de recursos alocados. E promessas não cumpridas, cedo ou tarde, cobram seu preço.

Esse post foi baseado em experiências recentes
em algumas das maiores instituições financeiras do país.