Choose a deduplication key
Use a source-provided event ID when it is unique and stable; otherwise derive a key from fields that identify the same business event. Avoid using only arrival time or a broad entity ID, which can either miss duplicates or merge distinct updates.
Persist the key and processing state atomically with the business result where the storage model allows it. Define how long deduplication records must remain, considering delayed retries and replay windows.
Make retries safe
Before sending a message, creating a payment, or changing an external record, check whether that effect was already completed or use the destination's idempotency support. A workflow restart should be able to continue from recorded progress.
Test duplicate, delayed, and out-of-order events, including two workers receiving the same event concurrently. Monitor duplicate detections and rejected events so a faulty key does not silently discard legitimate work.