Client-Side Dedup Sets vs Sink-Side Unique Constraints for Exactly-Once Write Retries

Julia's Base.retry(f; delays, check) re-executes a zero-argument function on failure, but provides no built-in idempotency guarantee. When f performs a write operation, a retry after a partially successful attempt can duplicate the effect, particularly for append-style writes such as push!, logging, or message-queue produce.

Two documented approaches exist for making retries safe: client-side deduplication, which tracks sent operation keys in an in-memory Set, and sink-side deduplication, which relies on database unique constraints or broker-level idempotence to enforce exactly-once semantics.

The choice between these approaches hinges on the constraint of maintaining exactly-once guarantees across process crashes, as client-side Sets are lost on restart and do not prevent duplicates after termination, while sink-side constraints may require schema modifications or protocol alignment with the downstream system. Under what conditions does a client-side dedup Set reliably prevent duplicate records after a crash-and-restart? Does sink-side unique constraint enforcement introduce latency or contention during high-concurrency retries? How should the dedup key be derived deterministically from logical content to avoid collisions across batched operations?