Black Friday 2024. Um vendedor operava três lojas a partir de um único armazém, e os pedidos do TikTok Shop chegavam ao WMS com seis horas de atraso. O SKU campeão esgotou em quarenta minutos; a plataforma ainda mostrava estoque disponível. Mais de trezentas over sells, e a linha de atendimento ao cliente derreteu. A equipe do armazém se sentiu injustiçada — o estoque estava lá; os pedidos apenas chegaram tarde. A causa raiz não estava no armazém. Estava no design da ingestão de pedidos, mal escolhido desde o primeiro dia.
Há dez anos, multicanal significava «temos uma loja na Shopify». Hoje é Shopify, Amazon, TikTok Shop e Walmart ao mesmo tempo, com pedidos entrando num único WMS por quatro frentes. Há apenas dois jeitos de canalizá-los: o polling — perguntar a cada plataforma a cada poucos minutos «tem pedido novo?» — ou os webhooks, em que a plataforma envia os pedidos novos no momento em que acontecem. A escolha decide se a latência dos seus pedidos se mede em minutos ou em segundos, e se você dorme ou apaga incêndios no dia de pico.
A diferença não é só velocidade
A maioria trata isso como uma escolha entre rápido e lento. Isso é ingênuo. As duas abordagens diferem em quatro eixos:
Latência. A latência do polling equivale ao seu intervalo de consulta — consulte a cada cinco minutos e a latência média é de dois minutos e meio. Os webhooks enviam em segundos. Ninguém nota dois minutos e meio numa terça-feira normal. Quando um SKU campeão esgota em quarenta minutos, esse atraso multiplicado por quatro plataformas é over sell.
Custo. O polling gasta seu orçamento de chamadas de API. A SP-API da Amazon impõe limites de taxa rigorosos; ultrapasse sua cota e você será limitado. Quanto maior o volume, mais você consulta, mais perto navega do muro do limite de taxa. Os webhooks não consomem sua cota — a plataforma envia, você recebe.
Confiabilidade. O polling raramente perde um pedido — se você perguntou, obteve a resposta. Os webhooks morrem de dois jeitos: a plataforma enviou e você nunca recebeu (uma oscilação de rede), ou você recebeu e não processou direito (reinício do serviço). Por isso webhooks exigem retentativas e idempotência: o mesmo pedido enviado três vezes deve existir exatamente uma vez no WMS. Já vi mais de uma operação aprender isso durante o pico, quando a criação duplicada de pedidos significou envios em dobro.
Suporte de plataforma. Nem toda plataforma oferece webhooks. Os da Shopify são maduros, o TikTok Shop fornece notificações push de pedidos, a Amazon se apoia no seu mecanismo de Notificações SP-API — cada um com sua própria semântica. Confira a documentação atual de desenvolvedor de cada plataforma; não aplique o conhecimento de integração do ano passado às APIs deste ano.
O caso da Amazon merece um aviso especial. Os limites de taxa da SP-API são por operação e realmente aplicados — conheço um 3PL que consultou o status dos pedidos de forma agressiva durante um pico de Prime Day, foi limitado durante boa parte de uma hora, e passou essa hora no escuro enquanto os pedidos se acumulavam. A correção deles foi um limitador token-bucket do próprio lado mais backoff exponencial, que é o que deveriam ter construído no primeiro dia. Se você faz polling na Amazon, orce sua cota como dinheiro: atribua a cada tarefa uma cota de chamadas, registre o consumo e alerte aos 80%. Ser limitado durante o pico é um ferimento autoimposto.
Minha recomendação: escolha pelo volume de pedidos
Esqueça o debate tecnológico. Olhe para o seu próprio volume e pegue a faixa correspondente:
Menos de 500 pedidos por dia: o polling basta. Consulte as quatro plataformas a cada cinco minutos. A latência é aceitável, o desenvolvimento leva alguns dias de um engenheiro. Invista o tempo economizado na reconciliação.
De 500 a 5.000 por dia: webhooks como principal, polling como backup. Os webhooks cuidam do tempo real; uma extração completa por hora captura o que os webhooks deixaram cair. A melhor combinação de valor por esforço que conheço, e a configuração mais comum entre os vendedores de médio porte com quem trabalhei.
Mais de 5.000 por dia: webhooks para uma fila de mensagens, mais reconciliação. Os envios caem numa fila para absorver os picos, os consumidores deduplicam de forma idempotente, e uma reconciliação total noturna compara os pedidos da plataforma com os pedidos do WMS. Faça teste de carga numa tempestade de envios antes do pico — as plataformas enviam mais tarde e duplicam mais durante os próprios grandes eventos, e entrar sem teste é voar no escuro.
Seja qual for sua faixa, três regras são inegociáveis. Uma: faça do ID de pedido da plataforma uma chave única global e descarte duplicatas silenciosamente. Duas: sempre verifique as assinaturas dos webhooks — já vi uma operação pular a verificação para economizar tempo e ficar com o banco de dados inundado de pedidos falsificados. Três: mantenha rodando uma tarefa de reconciliação total por hora. Este é o seguro de vida de todo armazém multicanal — webhooks falham, polling perde pedidos, a reconciliação não mente.
Essa tarefa de reconciliação merece uma nota de design própria, porque a maioria das equipes a constrói errado. Não compare «pedidos criados na última hora» — compare o conjunto completo de pedidos em aberto de cada plataforma com os pedidos em aberto no WMS, por ID de pedido da plataforma. A tarefa deve produzir exatamente três listas: pedidos da plataforma ausentes no WMS (lacuna de ingestão — busque-os), pedidos do WMS ausentes na plataforma (cancelados ou reembolsados na origem — sinalize para revisão), e divergências de status (enviado de um lado, pendente do outro — investigue). Rode-a de hora em hora, alerte alguém sobre a primeira lista, e registre as outras duas. Uma hora de engenharia aqui salva uma Black Friday.
Aquele vendedor da história de abertura? Migrou para webhooks mais reconciliação por hora. A Black Friday seguinte: 20.000 pedidos em quatro plataformas, zero over sells. Nenhum padrão de ingestão é inerentemente superior — existe apenas aquele que corresponde ao seu volume. Conte seus pedidos primeiro, depois escolha o canal. Nunca o contrário.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
