FDE Times: transactional outbox with Postgres and Python — no lost events, duplicates only if the receiver skips dedup
A 6 November FDE Times hands-on guide builds a Postgres outbox + polling relay with SKIP LOCKED, shows why “no lost events” still means at-least-once delivery, and puts Idempotency-Key / processed_events on the receiver to make retries safe.
Save an order then call the customer’s webhook and you get the dual-write problem: either the order commits and the ERP never hears, or the ERP receives an order your database rolled back. FDE Times builds a transactional outbox in Postgres and Python that FDEs can take to a customer site.
Write the business row and the outbox event in one transaction; a polling relay with FOR UPDATE SKIP LOCKED posts afterwards. Per-event commits limit how many already-delivered events get resent when one POST fails mid-batch. There is still no way to erase a duplicate delivery — only to make it harmless.
“No lost events” therefore means at-least-once. The receiver (or a buffer you control) must dedup by event ID — e.g. Idempotency-Key plus a processed_events insert in the same transaction as the business change. If the customer’s API already supports Stripe-style keys, ask how long they keep them and never mint a new key per retry.
For FDE and integration roles, phrases like at-least-once, idempotency, webhook and CDC are the signal; a kill-mid-flight test proving no lost events and no duplicate processing is the evidence.
Source: fdetimes.net