Context
Bázico is a fashion brand with an e-commerce operation. Orders start in Shopify, invoices and stock live in Bling, and customer messages go out on WhatsApp through Gupshup.
The flows that connect these platforms run in , which I chose for orchestration, and write to on Supabase.
The problem
E-commerce platforms deliver "at least once": when they do not get an acknowledgment in time, they send the same event again. Two events for the same order can also arrive almost together.
The customer felt it: the same WhatsApp message could go out twice for the same order.
The decision: deduplicate in the database
A "did I already send for this order?" check inside the flow does not solve it. Two concurrent events run the query at the same time, both read "no" and both send.
So the rule lives in PostgreSQL: a stops the same order from triggering the dispatch twice. The second record hits the index and never becomes a second send. The guarantee is atomic, because the database decides, not the order in which the flows run.
When a send fails
Failed sends go to a table and are retried the next day, without holding up new dispatches.
What this does not solve
Exactly-once delivery to the end customer cannot be guaranteed. If Gupshup accepts the message and the response is lost on the way back, the system has no way to tell whether it went out. The index guarantees the system never dispatches twice; what happens after the provider is outside its reach.
Outcome
The flows are in production, and dispatch is now deduplicated in the database before sending. The code is internal, so there is no link.