Long Polling vs. WebSocket vs. SSE: escolhendo o modelo certo de tempo real

O que é long polling e como difere do polling regular

A evolução 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 não 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 notificação" e fica suspensa sem consumir uma thread ativa (com async/await em servidores modernos). Quando um evento ocorre (nova mensagem, atualização de status, dado disponível), o servidor notifica todos os long poll pendentes, que então 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 atualizações. Esse ciclo contínuo cria a ilusao de uma conexão 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 conexões 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 recuperação 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 configuração especial. WebSocket exige que proxies e load balancers suportem o protocolo de upgrade e conexões TCP de longa duração, o que não é 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 são bloqueados pela infraestrutura, ou quando a frequência de atualizações é baixa e o overhead por ciclo é aceitável.

Implementando long polling no backend

Padrao eficiente com async e notificações

A implementação ingênua de long polling usa threads bloqueadas aguardando eventos, o que limita drasticamente a concorrência: 1.000 conexões pendentes bloqueiam 1.000 threads. A implementação correta usa operações assíncronas com TaskCompletionSource (em .NET), CompletableFuture (em Java) ou Promise (em Node.js), permitindo que uma única thread gerencie milhares de conexões 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 função 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 sincronização 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 - conexões pendentes por servidor

Limites práticos do long polling em produção

O maior desafio de escalabilidade do long polling é o número de conexões HTTP simultâneas pendentes por servidor. Cada conexão 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 conexões pendentes simultâneas com uso de memória razoável. Servidores baseados em thread-per-request como Tomcat clássico ou Django síncrono são inadequados para long polling em escala, pois cada conexão pendente bloqueia uma thread permanentemente. Monitorar número de conexões abertas, latência de resposta e consumo de memória por conexão é 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 não é viável, integração com APIs de terceiros que só oferecem long polling (como algumas APIs de pagamento e IoT), e quando a frequência de atualizações é baixa (uma vez por minuto ou menos) tornando o overhead por ciclo negligenciável. Webhooks são a alternativa server-to-server, mas long polling é necessário quando o cliente não tem IP fixo para receber webhooks. Sistemas de votacao ao vivo, notificações de status de processo assíncrono e consultas de resultado de jobs longos são casos onde long polling é perfeitamente adequado sem complexidade adicional.

Migração de long polling para WebSocket

Evoluindo a infraestrutura gradualmente

A migração de long polling para WebSocket pode ser feita de forma incremental sem downtime. Uma abordagem comum é usar uma biblioteca de abstração 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 correlação, esquema de payloads) pode ser mantido idêntico entre as duas implementações, 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 produção até ter certeza de que 100% dos clientes conseguem conectar via WebSocket.

Conclusao - long polling como solução 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.

Long Polling - Vídeos Essenciais

Long Polling vs WebSocket vs SSE explicados

Implementando long polling com async no backend

Comunicação em tempo real - comparativo de técnicas

Backoff exponencial e jitter em clientes HTTP

Polling patterns em sistemas distribuídos

Escalando conexões HTTP de longa duração