Webhooks e arquitetura orientada a eventos costumam ser apresentados como opções concorrentes. É melhor entendê-los como padrões em níveis diferentes.
Um webhook normalmente é um callback HTTP: quando algo acontece, um sistema envia uma requisição a um endpoint de outro. Arquitetura orientada a eventos descreve sistemas que publicam e reagem a eventos, frequentemente por um broker ou plataforma de streaming. Um webhook pode transportar um evento, mas não oferece automaticamente durabilidade, fan-out, replay, ordenação ou isolamento entre consumidores.
Escolha pelo contrato de integração
Webhooks funcionam bem quando o produtor conhece o endpoint, a quantidade de consumidores é administrável, a notificação próxima do tempo real é útil e a entrega HTTP é aceitável. São acessíveis para parceiros externos.
Eventos com broker tornam-se atraentes quando vários consumidores independentes precisam do mesmo fato, produtores não devem conhecer consumidores, o tráfego chega em rajadas, replay é importante ou consumidores avançam em velocidades diferentes.
Nenhuma opção elimina falhas distribuídas. Redes expiram, consumidores ficam indisponíveis e confirmações se perdem.
Projete para entrega pelo menos uma vez
Sistemas práticos podem entregar o mesmo evento mais de uma vez. Consumidores precisam ser idempotentes. Atribua um identificador estável ao evento e armazene estado suficiente para reconhecer o retry. Se a operação de negócio possui uma chave natural de idempotência, preserve-a por todo o workflow.
Não trate timeout HTTP como prova de que o receptor não fez nada. Ele pode ter confirmado a operação e perdido a resposta. Repetir sem idempotência pode duplicar pagamentos, mensagens ou transições.
Retries devem usar backoff exponencial limitado com jitter. Ao esgotar a política, mova o evento para um caminho recuperável, como dead-letter queue ou histórico visível ao operador. Retries infinitos e invisíveis escondem incidentes.
Proteja a fronteira
Receptores de webhook devem verificar uma assinatura sobre o payload original, impor tolerância de timestamp contra replay e comparar assinaturas em tempo constante. Faça rotação segura de secrets e documente como testar a verificação.
Autenticação não substitui validação. Trate o evento como entrada não confiável, limite o payload, valide o schema e autorize o efeito. Em plataformas internas, aplique identidade, criptografia, autorização por tópico, schema e isolamento entre tenants.
Torne evolução e ordenação explícitas
Versione schemas e prefira mudanças retrocompatíveis. Consumidores devem ignorar campos desconhecidos; produtores não devem remover ou reinterpretar campos sem migração.
Ordenação global é cara e raramente necessária. Defina o menor domínio que exige ordem — como os eventos de um pedido — e particione por ele. Consumidores ainda precisam lidar com atraso, duplicação e ausência eventual.
Observe a entrega como produto
Acompanhe latência, tentativas, sucesso, idade da fila, dead letters, lag e resultados. Ofereça uma forma segura de inspecionar e repetir falhas. Use identificadores de correlação de ponta a ponta.
A pergunta não é apenas “webhook ou eventos?”. É qual contrato de entrega o negócio exige — e se o desenho torna duplicação, atraso, falha, segurança e recuperação explícitos.
Referência
O artigo da AWS Builders’ Library sobre timeouts, retries e backoff com jitter explica por que retries precisam de limites e atrasos aleatórios em sistemas distribuídos.