Ask HN: How do you handle duplicate side effects when jobs, workflows retry?

Re:Ask HN: How do you handle duplicate side effects when job... by stephenr on Friday February 27, 2026 @02:52AM (#47177803)

I think the answer is probably like most things: it depends.

- If the external service supports idempotent operations, use that option.

- If the external service doesn't, but has a "retrieval" feature (i.e. lookup if the thing already exists, e.g fetch refunds on a given payment), use that first.

- If the system has neither, assess how critical it is to avoid duplicates.

[ Parent | on HN ]

Re:Ask HN: How do you handle duplicate side effects when job... by shineDaPoker on Friday February 27, 2026 @04:18AM (#47178441)

This matches my thinking. The retrieval/lookup approach is exactly what I built - basically Option C with an observe-before-act pattern.

For APIs that support idempotency keys (Stripe, etc.), I use those. For ones that don't but have retrieval (most do), I check first before retrying.

The question I'm wrestling with: is the extra round-trip for the lookup worth it? Or should I just accept the edge cases where it duplicates?

What's your threshold for "critical enough to avoid duplicates"? Payments obviously yes, but what about notifications, reporting, analytics events?

[ Parent | on HN ]