Foto: Jungwoo Hong / Unsplash
Automações
Montar a automação supondo que os eventos chegam na ordem em que aconteceram faz o status de um pedido ser sobrescrito por uma notícia mais velha
Pedro Toledo · 7 de novembro de 2026 · 3 min de leitura
Montar a automação supondo que os eventos chegam na ordem em que aconteceram faz o status de um pedido ser sobrescrito por uma notícia mais velha — porque o envio de eventos por webhook pode atrasar, repetir ou inverter a ordem, e uma automação que grava cada evento ao chegar pode trocar um 'pago' por um 'pendente' que foi gerado antes. Por que a ordem de chegada parecer a ordem dos fatos, o que caracteriza uma automação tolerante a eventos fora de ordem, e como testar com sequências embaralhadas.
Receber os eventos um depois do outro nos testes costuma parecer prova de que a ordem está garantida. Embaralhar de propósito dois eventos de um pedido, e ver qual estado a automação grava no fim, mostra se ela aguenta a ordem real da produção.
Montar a automação supondo que os eventos chegam na ordem em que aconteceram faz o status de um pedido ser sobrescrito por uma notícia mais velha.
Por que a ordem de chegada parece a ordem dos fatos
Nos testes, os eventos chegam um depois do outro, na sequência em que foram gerados, e a automação grava cada um ao receber. Na produção, o transporte pela rede, os reenvios e o processamento em paralelo podem fazer um evento mais antigo chegar depois de um mais novo, e a automação, sem saber, volta o pedido a um estado que já passou.
O que caracteriza uma automação tolerante a eventos fora de ordem
Uma automação tolerante trata o evento como um sinal, relê o estado atual do objeto na fonte, usa versão ou sequência quando existem e ignora eventos repetidos. Isso tem relação direta com processar o webhook inteiro antes de responder ao sistema de origem — os reenvios, que aquele problema provoca, são justamente uma das causas de eventos repetidos e fora de ordem, e a automação precisa tolerar os dois.
O que as fontes dizem
Não encontrei a página oficial da Stripe. Guias de terceiros que a descrevem dizem que não há garantia de ordem na entrega, que o horário de criação do evento não serve para ordenar e que se deve reler o estado atual pela API, usar versão ou sequência para rejeitar atualizações antigas e guardar os identificadores dos eventos já tratados. Os detalhes devem ser conferidos na documentação do provedor usado.
Como testar com sequências embaralhadas
A forma prática é gerar, em ambiente de teste, sequências de eventos fora de ordem ou repetidos — por exemplo, "pago" antes de "criado", ou "cancelado" depois de "pago" — e conferir se o registro final mostra o estado mais recente. Também vale guardar o identificador de cada evento processado e registrar quando um evento antigo é ignorado, para que a equipe veja o que aconteceu.
Um exemplo prático
Uma loja atualiza o status do pedido a cada evento do gateway de pagamento. Um dia, o evento "pagamento pendente" chega depois de "pagamento aprovado", e o pedido volta a pendente, sem a mercadoria ser enviada. Depois, a loja passa a consultar o estado atual do pagamento na API a cada evento, a gravar só se for mais recente e a testar com sequências embaralhadas.
O ponto central
Antes de gravar o que chegou, vale perguntar se é a notícia mais recente. A ordem em que os eventos chegam é a do transporte, e a ordem em que aconteceram só se sabe consultando a fonte.
