Webhook, WebSocket ou consulta periódica: qual usar em cada caso

Publicado em 2026-09-12 por frfrand

Tres formas de enterarse de que algo pasó, con costos muy distintos. Cuatro preguntas que resuelven la decisión sin discutir arquitectura.

As três resolvem o mesmo problema de fundo: ficar sabendo que algo aconteceu. Elas diferem em quem fala primeiro, quanto custa mantê-lo e o que acontece quando algo falha.

As três, em uma linha cada uma

Consulta periódica (polling). Você pergunta de vez em quando. Simples, sem nada que manter ativo.

Webhook. O outro serviço te chama quando algo acontece. Sem conexão permanente, mas você precisa de um endereço público.

WebSocket. Uma conexão aberta nos dois sentidos. Latência mínima, em troca de manter essa conexão por cliente.

As quatro perguntas

1. Quem inicia a conversa?

Se quem sabe de algo novo é um serviço externo (uma plataforma de pagos, GitHub, WhatsApp), a resposta é webhook. Não há discussão: é o mecanismo que esses serviços oferecem.

Se quem sabe de algo novo é seu próprio backend e o destinatário é um navegador, veja as outras duas.

2. Com que frequência?

Eventos por hora → webhook ou consulta periódica. Eventos por segundo → WebSocket.

Manter mil conexões abertas para avisar de algo que acontece três vezes por dia é caro em manutenção e em recursos.

3. É necessário ir e voltar?

Se o cliente apenas recebe (notificações, progresso de uma tarefa, um painel que se atualiza), Server-Sent Events costuma ser melhor que um WebSocket: funciona sobre HTTP normal e o navegador se reconecta sozinho.

O WebSocket se justifica quando o cliente também envia com frequência: um chat, um editor colaborativo, um jogo.

4. O que acontece se chegar atrasado?

Se um atraso de trinta segundos não muda nada, consulta periódica e está bom. É a opção mais chata e a que menos quebra.

Por que a consulta periódica não é a opção perdedora

Tem má fama e merece uma defesa, porque em produção ganha mais seguido do que se admite:

• Não há conexões que manter nem reconexões que implementar.
• Recupera sozinha: se uma consulta falhar, a próxima coloca tudo em dia.
• Escala sem pensar: qualquer servidor pode responder, não é preciso que o cliente volte sempre ao mesmo.

Quando o volume é o problema, há formas intermediárias: pedir apenas o que mudou desde a última vez, ou deixar a requisição esperando até que haja novidades (long polling), que dá latência quase de tempo real com muito menos complexidade.

O erro clássico

Escolher WebSockets porque soa moderno, e descobrir três meses depois que é preciso resolver: reconexão, recuperação das mensagens perdidas enquanto estava desconectado, sessões pegajosas no balanceador, limites de descritores abertos, e um Redis para repartir entre servidores.

Tudo isso é trabalho real e permanente. Vale a pena quando o produto precisa. Não vale a pena para atualizar um contador a cada minuto.

O mais comum na vida real

A maioria dos sistemas usa duas das três, não uma só.

Um exemplo típico: webhooks para ficar sabendo do que acontece fora (pagamentos, mensagens, repositórios), WebSocket ou SSE para a parte da interface que realmente precisa ser vista ao vivo, e consultas periódicas para tudo o mais.

Escolher uma única tecnologia para tudo é o caminho mais curto para se dar mal com ela.