Voce acabou de descobrir que seu sistema notifica o cliente 40 minutos depois do pagamento. O motivo? Polling a cada 5 minutos. E a culpa nao e do codigo, e do mecanismo. A escolha entre polling e webhook define latencia, custo de infraestrutura e a saude mental de quem mantem a integracao. Este comparativo analisa os dois lado a lado por criterio objetivo, sem viés de hype.
Latencia: quem entrega mais rapido
Polling entrega informacao no maximo no intervalo configurado. Se voce consulta a cada 60 segundos, o atraso medio e de 30 segundos. Em eventos raros, voce gasta requisicoes sem retorno. Webhook entrega no momento do evento, com latencia de milissegundos. Para pagamentos, webhook vence quando o evento e imprevisivel, como uma confirmacao de boleto que chega as 3h da manha. Polling so faz sentido quando o evento tem horario conhecido, como um relatorio diario.
Custo de infraestrutura e trafego
Polling gera trafego constante. Cada requisicao HTTP custa processamento no servidor e na sua aplicacao. Em escala, 10 mil clientes consultando a cada minuto resultam em 14,4 milhoes de requisicoes por dia, a maioria sem dados novos. Webhook inverte a logica: o servidor envia apenas quando ha novidade. O custo migra para o receptor, que precisa manter um endpoint publico e processar as chamadas recebidas. Para quem paga por requisicao, webhook tende a ser mais barato em eventos esporadicos.
Complexidade de implementacao
Polling e trivial: um loop com intervalo fixo e uma chamada GET. Nao exige infraestrutura publica nem tratamento de assinatura de payload. Webhook exige endpoint acessivel pela internet, validacao de autenticidade (geralmente por assinatura HMAC) e logica de reprocessamento. A doc da Asaas, por exemplo, alerta que se qualquer problema de comunicacao ocorrer com sua API, a fila e interrompida e voce recebe um email de notificacao. Ou seja: webhook resolve em tempo real, mas cobra em complexidade operacional.
Confiabilidade e tratamento de falhas
Polling e naturalmente resiliente: se uma requisicao falha, a proxima tenta de novo no intervalo seguinte. Webhook depende do receptor estar online. Se o endpoint cai, o evento pode ser perdido, a menos que o provedor implemente retry com backoff. Para cenarios criticos, o padrao recomendado e hibrido: webhook como canal principal e polling periodico como verificacao de consistencia. Nenhum mecanismo sozinho garante entrega perfeita.
Tabela comparativa resumida
| Criterio | Polling | Webhook | | --- | --- | --- | | Latencia | Ate o intervalo configurado | Quase imediata | | Custo de trafego | Alto em eventos raros | Baixo, proporcional a eventos | | Complexidade | Baixa | Alta (endpoint, assinatura, retry) | | Resiliencia a falhas | Alta por natureza | Depende de retry do provedor | | Caso ideal | Eventos previsiveis e frequentes | Eventos imprevisiveis e urgentes |
Veredito: qual escolher
Para quem busca simplicidade e eventos previsiveis, como sincronizacao diaria de dados, polling e a escolha certa. Para quem precisa de notificacao imediata de pagamento ou acionamento de alerta, webhook e superior, desde que voce aceite a responsabilidade de manter o endpoint e tratar falhas. Na duvida, implemente webhook e adicione um polling de seguranca a cada hora. Voce paga um pouco mais em trafego, mas dorme tranquilo sabendo que o evento nao se perdeu.
FAQ
Quando usar polling em vez de webhook?
Use polling quando os eventos ocorrem em intervalos regulares ou quando voce nao controla o endpoint de recebimento. Exemplos: consulta de status de envio a cada 30 minutos ou sincronizacao de catalogo diario. Polling tambem e util em ambientes com firewall que bloqueiam conexoes de entrada.
Webhook e sempre mais rapido que polling?
Sim, em termos de latencia media. Webhook entrega no instante do evento; polling entrega no proximo ciclo de consulta. Se o intervalo for de 1 minuto, a latencia media do polling e 30 segundos. Para eventos urgentes, webhook e a unica opcao aceitavel.
Como garantir que um webhook nao se perca?
Implemente retry com backoff exponencial no provedor e armazene o payload recebido em fila antes de processar. Adicione um polling periodico como verificacao de consistencia. Provedores como Asaas interrompem a fila em caso de falha de comunicacao e notificam por email, entao monitore esses alertas.
Polling gasta mais banda que webhook?
Depende da frequencia de eventos. Se eventos sao raros, polling gasta muito mais trafego, pois consulta sem retorno. Se eventos sao constantes, a diferenca diminui. Em APIs pagas por requisicao, o custo do polling pode inviabilizar o produto em escala.
Preciso de endpoint publico para receber webhook?
Sim, o provedor precisa acessar sua URL via internet. Em desenvolvimento, use ferramentas de tunel como ngrok. Em producao, o endpoint deve ter HTTPS e validar a assinatura do payload para evitar chamadas falsas.
O que e mais facil de testar: polling ou webhook?
Polling e mais facil, pois voce apenas executa a chamada e verifica a resposta. Webhook exige simulacao de eventos do provedor e validacao de assinatura. A maioria dos provedores oferece um painel para disparar eventos de teste manualmente, o que ajuda na validacao inicial.