At least once means idempotent consumers

Before you start

• Queues

  Work moves off the request path into a queue.

  Open lesson

Why it matters

A queue can redeliver m1 after a worker finishes but loses its acknowledgement, and a push provider can time out after actually notifying Ana. Another delivery may keep failing because its device token is invalid. Duplicate suppression needs a stable id all the way to the side effect, and one poison message must never stall the queue.

After a post, you email or push the mentioned users. The push provider fails some requests and succeeds if you try again.

Input

deliveries = [["m1", "ana"], ["m2", "bo"], ["m1", "ana"], ["m3", "cy"], ["m2", "bo"]]

Output

["ana", "bo", "cy"]

Give Ana’s notification the stable id m1 and carry it into the side effect: transact it with local work or use it as the push provider’s idempotency key. Then retry temporary failures and dead-letter a bad token so m2 and m3 continue.

Publish m1 for Ana with a stable id. For a database effect, write m1 and the effect in one transaction. For an external push, pass m1 as the provider’s idempotency key. A local processed set alone cannot close the gap between provider success and a worker timeout.

Retry a temporary provider failure with increasing delays and jitter. After a fixed attempt limit, move a dead-token message to a dead-letter queue and continue with m2 and m3. This isolates poison work, but delivery remains best effort because the provider call and local id record are not one transaction.