Contexto
A Bázico é uma marca de moda com operação de e-commerce. O pedido nasce na Shopify, a nota e o estoque ficam no Bling, e a comunicação com o cliente sai por WhatsApp, pela Gupshup.
Os fluxos que ligam essas plataformas rodam em , que escolhi para a orquestração, e gravam em , no Supabase.
O problema
Plataformas de e-commerce entregam "pelo menos uma vez": se não recebem confirmação a tempo, mandam o mesmo evento de novo. Dois eventos do mesmo pedido também podem chegar quase juntos.
O efeito chegava ao cliente: a mesma mensagem de WhatsApp podia sair duas vezes para o mesmo pedido.
A decisão: deduplicar no banco
Uma checagem do tipo "já enviei para este pedido?" feita no fluxo não resolve. Dois eventos simultâneos fazem a consulta ao mesmo tempo, os dois leem "não" e os dois enviam.
Por isso a regra ficou no PostgreSQL: um impede que o mesmo pedido gere o disparo duas vezes. O segundo registro colide com o índice e não vira um segundo envio. A garantia é atômica, porque quem decide é o banco, não a ordem em que os fluxos rodam.
Quando o envio falha
O que falha vai para uma tabela de e é tentado de novo no dia seguinte, sem travar os disparos novos.
O que ficou de fora
Entrega exatamente uma vez ao cliente final não dá para garantir. Se a Gupshup aceita a mensagem e a resposta se perde no caminho, o sistema não tem como saber se ela saiu. O índice garante que o sistema não dispara duas vezes; o que acontece depois do provedor fica fora do alcance dele.
Resultado
Os fluxos estão em produção, e o disparo passou a ser deduplicado no banco antes do envio. O código é interno, por isso não há link.