Long Polling: simulando tempo real com HTTP antes do WebSocket

O que é long polling e como difere do polling regular

A evolucao do polling tradicional para o modelo de espera ativa

Polling regular (short polling) é a abordagem mais simples para simular tempo real via HTTP: o cliente envia uma requisicao ao servidor periodicamente (a cada 1s, 5s, 30s) e o servidor responde imediatamente com os dados disponíveis ou uma resposta vazia. Esse modelo é simples de implementar mas ineficiente: a maioria das requisicoes retorna vazia, gerando tráfego desnecessário e aumentando o custo de infraestrutura. Long polling resolve o problema de respostas vazias: o servidor nao responde imediatamente, mas segura a requisicao aberta até ter dados novos para enviar, ou até um timeout configurável expirar. O resultado é uma troca de dados que parece em tempo real do ponto de vista do usuario, com muito menos requisicoes que o polling regular.

Como funciona — servidor segura a resposta

O mecanismo de espera no lado do servidor

Quando o servidor recebe uma requisicao de long polling, em vez de responder imediatamente, ele aguarda por um período até que um evento relevante ocorra. Internamente, isso pode ser implementado com um mecanismo de subscricao: a requisicao HTTP é registrada como "aguardando notificacao" e fica suspensa sem consumir uma thread ativa (com async/await em servidores modernos). Quando um evento ocorre (nova mensagem, atualizacao de status, dado disponível), o servidor notifica todos os long poll pendentes, que entao enviam suas respostas imediatamente. O cliente, ao receber a resposta, processa os dados e imediatamente abre uma nova requisicao de long polling para continuar recebendo atualizacoes. Esse ciclo contínuo cria a ilusao de uma conexao persistente sobre o protocolo HTTP stateless.

Timeout e reconexao — o loop do long polling

Gerenciando o ciclo de vida das requisicoes

Todo servidor de long polling precisa de um timeout máximo por requisicao (tipicamente 30-60 segundos) para liberar recursos e prevenir conexoes presas indefinidamente. Quando o timeout expira sem evento, o servidor responde com status 200 e payload vazio ou 204 No Content, sinalizando ao cliente que deve abrir uma nova requisicao. O cliente implementa o loop: ao receber uma resposta (seja com dados ou timeout vazio), ele imediatamente envia uma nova requisicao. Em caso de erro de rede ou status 5xx, o cliente deve aplicar backoff exponencial com jitter antes de reconectar, evitando tempestade de requisicoes simultâneas que poderia sobrecarregar o servidor durante recuperacao de falhas. Esse loop é simples de implementar com fetch e async/await em qualquer linguagem moderna.

Long polling vs WebSocket vs SSE — trade-offs

Escolhendo a tecnologia certa para cada contexto

Long polling opera sobre HTTP puro, sendo compatível com qualquer proxy, firewall corporativo e infraestrutura legada sem configuracao especial. WebSocket exige que proxies e load balancers suportem o protocolo de upgrade e conexoes TCP de longa duração, o que nao é universal em ambientes corporativos restritos. Server-Sent Events (SSE) é unidirecional e mais simples que WebSocket, mas compartilha algumas restricoes de proxy com WebSockets. Long polling tem overhead maior por requisicao (headers HTTP completos a cada ciclo) comparado ao WebSocket (frames minúsculos), tornando-o ineficiente para mensagens muito frequentes. A regra prática: use long polling quando WebSocket e SSE sao bloqueados pela infraestrutura, ou quando a frequência de atualizacoes é baixa e o overhead por ciclo é aceitável.

Implementando long polling no backend

Padrao eficiente com async e notificacoes

A implementacao ingênua de long polling usa threads bloqueadas aguardando eventos, o que limita drasticamente a concorrência: 1.000 conexoes pendentes bloqueiam 1.000 threads. A implementacao correta usa operacoes assíncronas com TaskCompletionSource (em .NET), CompletableFuture (em Java) ou Promise (em Node.js), permitindo que uma única thread gerencie milhares de conexoes pendentes. O servidor mantém um dicionário de waiters indexado por contexto (usuário, recurso, sala): quando um evento ocorre, o handler localiza os waiters relevantes e completa seus TaskCompletionSources, fazendo todas as requisicoes pendentes retornarem simultaneamente. Um timeout global usando CancellationToken garante que requisicoes sejam encerradas após o período máximo mesmo sem eventos, liberando recursos.

Implementando long polling no frontend

O loop de reconexao no cliente

No cliente, long polling é implementado com uma funcao assíncrona recursiva ou em loop: faz a requisicao, aguarda a resposta, processa os dados recebidos e imediatamente inicia uma nova requisicao. O parâmetro lastEventId ou um timestamp é enviado em cada requisicao para que o servidor saiba de onde retomar, evitando entregar eventos duplicados ou perdidos entre ciclos. A lógica de backoff é crítica: em caso de erro, espere 1s na primeira falha, 2s na segunda, 4s na terceira, até um máximo de 30-60s, adicionando jitter (variacao aleatória) para evitar sincronizacao de múltiplos clientes. Implemente também um mecanismo de visibilidade de página (Page Visibility API) para pausar o long polling quando a aba está em segundo plano e retomar quando volta ao foco.

Escalabilidade — conexoes pendentes por servidor

Limites práticos do long polling em producao

O maior desafio de escalabilidade do long polling é o número de conexoes HTTP simultâneas pendentes por servidor. Cada conexao consome um file descriptor do sistema operacional e memória para o estado da requisicao. Servidores Node.js e servidores .NET com Kestrel assíncrono conseguem manter centenas de milhares de conexoes pendentes simultâneas com uso de memória razoável. Servidores baseados em thread-per-request como Tomcat clássico ou Django síncrono sao inadequados para long polling em escala, pois cada conexao pendente bloqueia uma thread permanentemente. Monitorar número de conexoes abertas, latência de resposta e consumo de memória por conexao é essencial para dimensionar corretamente a infraestrutura de long polling.

Casos de uso onde long polling ainda faz sentido

Cenários onde a simplicidade supera a eficiência

Long polling ainda faz sentido em cenários específicos em 2026: ambientes corporativos com proxies que bloqueiam WebSocket, sistemas legados onde atualizar o servidor para suportar WebSocket nao é viável, integracao com APIs de terceiros que só oferecem long polling (como algumas APIs de pagamento e IoT), e quando a frequência de atualizacoes é baixa (uma vez por minuto ou menos) tornando o overhead por ciclo negligenciável. Webhooks sao a alternativa server-to-server, mas long polling é necessário quando o cliente nao tem IP fixo para receber webhooks. Sistemas de votacao ao vivo, notificacoes de status de processo assíncrono e consultas de resultado de jobs longos sao casos onde long polling é perfeitamente adequado sem complexidade adicional.

Migracao de long polling para WebSocket

Evoluindo a infraestrutura gradualmente

A migracao de long polling para WebSocket pode ser feita de forma incremental sem downtime. Uma abordagem comum é usar uma biblioteca de abstracao como Socket.IO que tenta WebSocket primeiro e cai automaticamente para long polling se WebSocket falhar, permitindo que ambos coexistam transparentemente. No backend, o contrato de dados (formato de eventos, IDs de correlacao, esquema de payloads) pode ser mantido idêntico entre as duas implementacoes, exigindo mudanca apenas na camada de transporte. Migre primeiramente os casos de uso com maior frequência de mensagens, onde o ganho de eficiência do WebSocket é mais significativo. Mantenha o suporte a long polling em producao até ter certeza de que 100% dos clientes conseguem conectar via WebSocket.

Conclusao — long polling como solucao pragmática

O valor do conhecimento de protocolos alternativos

Long polling raramente é a primeira escolha em sistemas novos, mas é uma ferramenta indispensável para compatibilidade com ambientes restritos e fallback de WebSockets. Entender como funciona internamente permite diagnosticar problemas de escalabilidade e implementar corretamente com async, timeout e backoff. Continue em: Fundamentos obrigatórios antes de produção.